(this message is half redundant now since there were some more posts since I typed it)
On Wednesday, 21 October 2020, Hal Murray <hmur...@megapathdsl.net> wrote: > > > Even if the network is lightly loaded, there can be asymmetry in CPU > processing delays. And that is why software timestamps (in a non-realtime OS) are the worst thing that can happen to synchronisation. > In traditional NTP, the transmit time stamp is grabbed as late as possible > before sending a packet.. That cancels out if both CPUs are the same > speed. > Adding authentication (crypto type computations) increases delay from grab > to > send. That will increase the offset if the CPUs are not matched. That is all only a part of the problem. NTP(/d) can't do anything about the fact that even once the socket send call is made, the kernel will essentially send the packet when it feels like it. Nothing can cancel out the unpredictable latency of software-driven interrupt handling either. Crypto or anything else in userspace after grabbing a timestamp is a killer to sync - PTP (2019) is attempting to do crypto via side channels. NTP's focus from its inception was on sync over the Internet, where the timestamping uncertainty component was negligible compared to the network component, and it was a similar case over early LANs. With today's network hardware this uncertainty can no longer be ignored. Now when I say NTP I mean the protocol, not it's implementations. > > There is work in progress at the IETF working group on an "interleaved" > mode > that would send the time stamp from one packet in the next packet. That > adds > a delay in getting the data which can't be good but I don't know how bad > it > is. I've been thinking that a system could measure that delay and add it > to > the time stamp. No code yet. Interesting - this is pretty much PTP's two-step mode. The only way to attempt at grabbing a TX timestamp sensibly in software is by the kernel, just before it passes the packet to hardware, and long after the application "sent" it, and Linux supports this. PTP's Follow-Up message is transmitted as soon as the TX timestamp is grabbed. This extra dead time is minimal. No way can that timestamp be transmitted in the original packet itself - that would be like PTP's one-step mode, but only hardware can do it. FPGA- or otherwise hardware-based NTP servers do this today. > > > -- > These are my opinions. I hate spam. > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.