[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[David L. Mills]

Stuart,

All three citizens are told only to keep the reciprocal delays as close 
as possible and minimize incidendal jitter. They don't see any capture 
point in the specification.

Media Herbie has no problem since his NIC strikes a transmit timestamp 
only if the carrier is down and the preamble is not jammed. He knows the 
packet he stamped got successfully out the door. Driver Sue has to be 
careful to strike the timestamps at NIC interrupt time; that is, just 
before the checksum for the transmit side and just after the checksum on 
the receive side. This makes sure that, even if the frame is 
retransmitted the strikes are true. If she is clever, she will know the 
line speed and add in 320 ns (at 100 Mb) on the transmit side to account 
for the 32-bit checksum.

Now, on the fastest machine I have it takes about 500 ns to read the 
system clock and the only thing she knows is that the true time is 
somewhere in the middle. Sue will need something better, like the PCC or 
TSC. THe real trick is to pass these timestamps upstack to the protocol 
machine, whether in FPGA (only for sissies), embedded RISC CPU on-chip 
(Intel) (for real programmers) or dreary ntpd.

Notice that the boys and girls can interoperate in a truly gender 
independent way.

So, where;s the beef?

Dave

STUART VENTERS wrote:

> Dave,
>
>
> Life is pretty good, we are generally in agreement on the 1st and 3rd 
> paragraph and the 2nd may have gone from futile to only un-necessary.
>
> Let me try a scenario based on my understanding of your second 
> paragraph and see where we end up.
>
> Say the NTP spec turns out like you want and an implementer (named 
> Herbie Worker) takes it and builds an NTP client and server. He's 
> building in an fpga and decides to strike timestamps when the start of 
> each packet enters and exits his host. (IE scarfed on the wire at 
> SOP.) He's careful and his timestamps have variances on say 40ns. 
> Furthermore, he decides to use the same timestamping design at both 
> the client and server. This makes guaranteeing the reciprocal match 
> automatic, since each direction passes a packet through identical time 
> strikers. He gets it all running and installs test wires on the time 
> counters at the client and server. From the test points, he notes that 
> on a point to point link the client is time aligned to the server 
> within 40ns. Herbie has successfully built a rigorous NTP 
> implementation and he is a happy camper. Marketing looks at the tests 
> and decides to sell an NTP implementation with an advertised accuracy 
> of 40ns.
>
> Another implementer (named Sue Worker) also decides to build an NTP 
> client and server from the spec. She's doing it in software, but has a 
> dedicated fast processor and after thinking about it decides to strike 
> timestamps as close to the hardware as she can which is in her 
> drivers. (IE scarfed in the drivers.) She's pretty sharp and figures 
> out that with a wire between the RX interrupt and her Hardware timers, 
> she can timestamp incoming packets to within 100ns. She also figures 
> out that by waiting until the transmitter is quiet before starting a 
> packet, she can control the timestamp outgoing packets to within 
> 100ns. She also has testpoints and her client is aligned to her server 
> within 100ns. Sue has successfully built a rigorous NTP implementation 
> an we have another happy camper. Marketing looks at the tests and 
> decides to sell an NTP implementation with an advertised accuracy of 
> 100ns.
>
> A third guy (named Pesky User) decides to do some time keeping and 
> builds a system using Herbie's server and Sue's client. He does so and 
> notices a time offset of a few microseconds. This seems contrary to 
> the specs, what's wrong? One answer is that Pesky, by plugging 
> together 2 stunning NTP implementations, essentially constructed a 
> third NTP implementation, but without enough rigor to ensure that the 
> reciprocal delays match.
>
> Pesky finds this answer unsatisfying, (after all, he's a user not an 
> implementer), and so the IETF reopens the NTP spec. The new spec 
> affirms Herbie's choice and Sue adds a minor compensation factor to 
> bring her implementation into compliance. Now Pesky can plug different 
> implementations together at will. Everybody is happy except for the 
> users with islands of Sue's original implementation.
>
>
> Ideally there is something wrong with my scenario or in my 
> understanding of what you are saying. I'd be perfectly happy to be 
> wrong if there is a simpler way to make a complete spec.
>
> If not, then IMHO, the NTP spec still needs tell Herbie and Sue that 
> they have to assure a reciprocal delay match. Since there are multiple 
> non-interoperable ways of doing so (for example the 2 above), it also 
> needs to give them a clue as to which one to use. I don't pretend to 
> know the best way to do this, but nailing down CP1 and CP2 is a 
> possibility.
>
>
> Regards,
>
> Stuart
>
>
>
> ps, It's possible that the reason we are here is that this is the 
> first time that it's become reasonable to implement NTP to a degree of 
> accuracy where this sort of precision in the spec matters.
>
> pps, It seems to me that NTP may already be superior to 1588 in 
> precision timekeeping applications where the packets have to go 
> through vanilla packet switches. It this case more measurement packets 
> means better odds of getting a lucky one. The followup packets are a 
> hindrance to more measurement packets. (Unless the followup packets 
> are also measurement packets, or you build a 1588 implementation which 
> doesn't need/use followup packets.)
>