[time-nuts] IEEE 1588 PTP support on raspberry pi 4 compute module

[Magnus Danielson]

Hi,

On 2020-10-22 01:28, Wojciech Owczarek wrote:
> Hi Bob,
>
> On Wednesday, 21 October 2020, Bob kb8tq <kb8tq at n1k.org> wrote:
>
>
>> *Networking* hardware is the issue …..
>>
> Undeniably so, but to what extent?
>
>
>
>> If you have fully symmetric delays, then there is no need for 1588. NTP
>> will
>> do just fine.
>
> Lab results and years of production deployment tell me otherwise. Hardware
> timestamps are the key. NTP *with hardware timestamps on both server and
> client* will do just fine, yes.
>
>
>> Unfortunately as even home networking hardware loads up,
>> ( = lots of traffic in only one direction) this may not be the case. When
>> things
>> *do* go asymmetric, then you *do* need 1588 compatible switches.
>>
>>
> Quantify "lots". My argument is that the uncertainty of software-generated
> timestamps can outweigh that of a network that isn't loaded up to choking
> point e.g. little to no buffering. Home traffic tends to be bursty, with
> occasional constant load and yes asymmetric. But your PTP device is not
> sitting on your ISP link, neither of them will, and unless your host
> running PTP is sitting on a saturated link, it really is not as bad as it
> may seem. Even cheap switches these days are non-blocking, so unless you
> have lots of multicast, PTP hosts on your network will not be critically
> affected by other traffic. Yes, they are store and forward, but it's about
> selecting packets in a band with minimum transit latency or, say, mode. The
> band has to be wide enough to catch at least one packet per second. With a
> rate of say 32 msg/sec chances of catching lucky packets increase. I can't
> normally take results out of my work lab unfortunately, but I think I might
> just drop a "home" switch in there and put some application traffic through
> it for a proper test. I know what difference a PTP transparent clock switch
> makes, but even without one, it really is "not that bad". Numbers or it
> didn't happen, so I'll ad that to my to-do list.

I've seen networks provide over 10 ms of time error due to asymmetry.

I've seen poor scheduling and such in the CPU, especially virtualized
enviroments, to be many minutes.

Yeah, poor CPU time-stamping can be worse than network biases, but
hardware time-stamping and careful use of good time-stamps handles most
of the host issues. Then network biases becomes the dominant problem
unless one does not have other implementation issues, and well, those
are common, including dropping PTP packets aimed for processing. In one
instance there was a rate-limit internal to the equipment that did the
wrong thing. Slowly the implementation issues is being ironed out. I
learn more of this than I want to.

Cheers,
Magnus