[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[STUART VENTERS]

Dave,

My apologies for not responding sooner to your Jan 23 E-mail, I got tied up.
The delay was good in the it has given me time to consider what you said.

Thank you for the further clarification as to the constraints of a S/W implementation of NTP on unix.  I had suspected as much from things done in an earlier life, but it is nice to hear from the person who best knows.  I agree with you that even with heroic efforts, it is likely impossible to implement an exact capture point in the environment where NTP mostly runs now.  That said, making a spec which requires doing so is futile.

Although I haven't had experience building NTP in S/W, I have experimented with it in H/W.  Many of the S/W constraints go away, and without heroic efforts I can strike timestamps with maybe 40ns accuracy.   The residual errors are due mostly to clock domain crossings between the Ethernet Rx and Tx clocks and the clock I use for timekeeping.  With more work these could be reduced but there will always be some residual error.  Even with H/W, making a spec which requires exact accuracy is futile.

So why do I still think that things that can't be controlled in the implementation need to be in the spec?

Stepping back, the NTP spec is strange compared to most IETF protocol specs.  Most protocol specs provide specific rules for communicating.  Close doesn't count, things have to be exact.  You wouldn't expect to see a spec that says use approximately this value for a message type or checksum.  As demonstrated above, timekeeping is different.  Close not only counts, it's all we can do.  But to get close, we need to match the reciprocal delays.  To do this with multiple implementations, we need to agree on CP1 and CP2.  The CP1/CP2 definitions are needed because without them, there are multiple incompatible ways to achieve matched reciprocal delays.

Perhaps a way out is to provide exact definitions for CP1 and CP2 as goals for the implementer.  Then provide profiles stating how close the implementer has to get to the goals.

Regards,

Stuart



ps, I wonder if there is some fpga eval card which would be a better deal than a $600 special 1588 nic.

pps, As for your other shoe, perhaps it should stay on.  It's not clear that the two step stuff is necessary and it's clearly not desirable to change the protocol.  If just before calculating the message digest, the transmit routine could look into the transmit system and predict when the packet would go out then it would be unnecessary.  If I remember correctly, the most popular communications processors used to provide enough information to do this.  Namely, a buffer descriptor list of packets yet to be sent and a current buffer pointer for the one being sent.  Seems like converting these to the approximate number of Ethernet clocks before the NTP packet goes out would be doable.  I expect that any 1588 implementation which needs the two step correction also needs special 1588 hardware for striking timestamps.  Maybe the 1588 hardware just needs to provide this prediction capability.  (Hopefully the 1588 H/W folks are listening.)  Of course this only works if the 1588 hardware is tightly integrated with the Etherent transmitter.  If the hardware is just watching the packets go by at the transmitter output, then maybe we see your sock.  (So, what's the url for the architecture briefing?)

ppps, There's another thing different about the NTP spec.  One technique for defining a protocol is to detail a sample implementation and then say that the protocol is what the implementation does.  It seems like the NTP spec does this a bit more than usual.  This is great as long as we remember we are making a protocol spec.