[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[David L. Mills]

Stuart,

I hear you, but we are not in agreement. I think we agree that NTP does 
not synchronize the clock to prevailing wire time; it synchronizes to a 
server clock by minimizing the computed offset relative to that clock. I 
think we agree that the only thing that matters is the reciprocal delays 
and the delay variations along the paths. Therefore, a definitive 
statement on the achievable accuracy depends only on the rigor with 
which this can be achieved.

I submit this has nothing to do with the formal NTP specification. 
Whether timestamps are scarfed on the wire, in the drivers or even as 
NTP does now is a matter of design, implementation and software/hardware 
capabilities. A clear statement about this should be in the spec along 
with plausible scenarios such as I summarized in a previous message.

I would hope the TICTOC WG would take this issue up and consider the 
proposition that, should wire timetamps such as captured in 1588 
hardware be available and the two-step NTP on-wire protocol be adopted, 
NTP accuracy could rival 1588. There are lots of wherefores and whyfores 
in this agenda and it is not intendded to compete with current 1588 
development, but it is an issue for research and experimentation.

Dave

STUART VENTERS wrote:

>
> 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.
>
>
>
>
>