[Linuxptp-devel] ptp4l and bonding

[Miroslav Lichvar]

I'm wondering what changes would ptp4l need in the kernel in order to
support operation with bonded interfaces as a PTP slave. Currently, as
I understand it, it doesn't work at all, at least with the UDP
transports. I'm not very familiar with the kernel code, please tell me
if what I say doesn't make any sense.

I think there are at least two possible approaches. One would be to
add support for timestamping on the master interface and the kernel
would send to sockets bound to the interface timestamps from
interfaces that are currently active. As each slave interface may have
its own clock, ptp4l would need to know from which interface the
timestamp is. When that source changes, ptp4l would need to update its
state and restart the servo. phc2sys would need to know about all
interfaces and select the one which is currently synchronized.

A simpler approach (at least on the ptp4l side) would be to allow
receiving and sending multicast packets on sockets bound to the slave
interfaces. For each slave interface there would be a separate ptp4l
instance running which would synchronize the clock when the interface
is active and is actually receiving/sending packets. For each ptp4l
there would be a phc2sys instance writing measurements to SHM or
phc2sys could be improved to support multiple ptp4l sources.

Would this require more than a new socket option in the kernel?

FWIW, in a test I did with a single bonded interface and the L2 transport
ptp4l was able to bind to the slave interface, send and receive
packets, and synchronize the clock. I didn't have a chance to try it
with multiple interfaces and other bonding modes. Does anyone know if
it would work?

Thoughts?

[Dale Smith]

I did try something like this at one time, but was unsuccessful
Unfortunately, I don't remember any details. My device has a P2020
processor with two gianfar interfaces. Both interfaces share the same
actual clock. (Seems like that could be used nicely as a boundary clock,
with one nic being the slave to some other master and servoing the hw
clock, and the other nic running as master for other downstream slaves).

I don't have any suggestions, but I'm very interested in seeing this
working.

-Dale

Post by Miroslav Lichvar
I'm wondering what changes would ptp4l need in the kernel in order to
support operation with bonded interfaces as a PTP slave. Currently, as
I understand it, it doesn't work at all, at least with the UDP
transports. I'm not very familiar with the kernel code, please tell me
if what I say doesn't make any sense.
I think there are at least two possible approaches. One would be to
add support for timestamping on the master interface and the kernel
would send to sockets bound to the interface timestamps from
interfaces that are currently active. As each slave interface may have
its own clock, ptp4l would need to know from which interface the
timestamp is. When that source changes, ptp4l would need to update its
state and restart the servo. phc2sys would need to know about all
interfaces and select the one which is currently synchronized.
A simpler approach (at least on the ptp4l side) would be to allow
receiving and sending multicast packets on sockets bound to the slave
interfaces. For each slave interface there would be a separate ptp4l
instance running which would synchronize the clock when the interface
is active and is actually receiving/sending packets. For each ptp4l
there would be a phc2sys instance writing measurements to SHM or
phc2sys could be improved to support multiple ptp4l sources.
Would this require more than a new socket option in the kernel?
FWIW, in a test I did with a single bonded interface and the L2 transport
ptp4l was able to bind to the slave interface, send and receive
packets, and synchronize the clock. I didn't have a chance to try it
with multiple interfaces and other bonding modes. Does anyone know if
it would work?
Thoughts?
--
Miroslav Lichvar
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Phil Reid]

Post by Miroslav Lichvar
I'm wondering what changes would ptp4l need in the kernel in order to
support operation with bonded interfaces as a PTP slave. Currently, as
I understand it, it doesn't work at all, at least with the UDP
transports. I'm not very familiar with the kernel code, please tell me
if what I say doesn't make any sense.
I think there are at least two possible approaches. One would be to
add support for timestamping on the master interface and the kernel
would send to sockets bound to the interface timestamps from
interfaces that are currently active. As each slave interface may have
its own clock, ptp4l would need to know from which interface the
timestamp is. When that source changes, ptp4l would need to update its
state and restart the servo. phc2sys would need to know about all
interfaces and select the one which is currently synchronized.
A simpler approach (at least on the ptp4l side) would be to allow
receiving and sending multicast packets on sockets bound to the slave
interfaces. For each slave interface there would be a separate ptp4l
instance running which would synchronize the clock when the interface
is active and is actually receiving/sending packets. For each ptp4l
there would be a phc2sys instance writing measurements to SHM or
phc2sys could be improved to support multiple ptp4l sources.
Would this require more than a new socket option in the kernel?
FWIW, in a test I did with a single bonded interface and the L2 transport
ptp4l was able to bind to the slave interface, send and receive
packets, and synchronize the clock. I didn't have a chance to try it
with multiple interfaces and other bonding modes. Does anyone know if
it would work?
Thoughts?

Not sure if I've got exactly the same setup as you but I think its similar.
I've got a EMAC with PTP hardware connected on a fixed link to a ethernet switch.
Which also has PTP timestamping, however no drivers exist for this feature as yet.

Anyway the EMAC PTP hardware (sync, PPS etc) works when the switch is configured
as a transarent device and the EMAC port has an IP address.

Hoever when configured using the Distributed Switch Architecture (DSA) driver the
PTP functionality doesn't work. If tried 802.3 transport with no effect. The
virtual ports on the DSA chip currently report:
interface 'lan1' does not support requested timestamping mode.
For all stamping options H/S/L options.

Just started looking at my options.
I was hoping to be able to use eth0 to stamp packets going out on virtual lan1, lan2
ports but so far no luck.

[Miroslav Lichvar]

Post by Miroslav Lichvar
FWIW, in a test I did with a single bonded interface and the L2 transport
ptp4l was able to bind to the slave interface, send and receive
packets, and synchronize the clock. I didn't have a chance to try it
with multiple interfaces and other bonding modes. Does anyone know if
it would work?

I tried the L2 transport with multiple bonded interfaces and it seems
to be working nicely. It looks like bonding doesn't really have any
effect on the raw sockets that ptp4l uses. They can send/receive
packets even when the slave interface is not currently active.

The only potential issue I see is that in bonding configurations where
the MAC addresses of the slave interfaces are set to the same address,
the PTP clocks have the same clock and port identities. If they were
PTP masters, that would be a problem. With the slave-only option (-s)
I think the worst thing that can happen is two slaves sending a delay
request close to each other and accepting a mismatched delay response,
which would add an error to the measured delay. As slaves randomize
sending of their delay requests, this should happen rarely and when it
does happen, the error will not get through the median filter, so I
think this won't really be a problem.

If anyone would like to try it, with the timemaster program the
configuration is simple. Just list the slave interfaces for the PTP
domain and enable the L2 transport, for example

[ptp_domain 0]
interfaces eth0 eth1

[ptp4l.conf]
network_transport L2


The question is if the same approach could be used with the UDP
transport. The kernel would need to allow sending and receiving
packets on sockets bound to the slave interfaces and I have no idea
what changes that would require.