[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamplocation

[TS Glassey]

This may be my fault... let me possibly spin a justification for what the 
group is trying to do.

Perhaps the issue here is that we have all forgotten that most SW models 
were built as emulations - so a SW version of the NTP system, is an 
emulation of a HW based appliance or service. That said there is a 
reasonable argument for assigning a particular point in time (or rather a 
point of the structure of the NTP Packet itself, which would be considered 
that point in time.

I think that the problem is that unlike 1588, the NTP process depends on 
some stack receiving and framing the data prior to its actually being 
reliable data. Since there are no precision timer/receipt processes 
available for logging in TCP, UDP,  or the NTP process to address this it 
becomes a real issue in that the data could sit in the stack for any amount 
of time...

However. In rethinking mo commentary I would now agree that tools like the 
TCP accelerator engines which reduce TCP and UDP communications to more 
appliance style communications in and of themselves demonstrate  a reason 
for allowing this event.

But perhaps the real issue isn't whether its a part of the packet frame that 
constitutes the physical "its now" marker  but rather when the 'device' (a 
Network Agent) actually constitutes the receipt point since nothing can be 
done by the stack until it passes those datum (no pun intended) to the NTP 
process or TOD services of the Host OS.

Does this make sense?

Todd

----- Original Message ----- 
From: "David L. Mills" <mills at udel.edu>
Cc: <ntpwg at lists.ntp.org>
Sent: Saturday, February 02, 2008 8:53 PM
Subject: Re: [ntpwg] ntpwg Updated NTPv4 Protocol 
Specification/timestamplocation


> 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.
>>
>>
>>
>>
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg