[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamplocation

[David L. Mills]

TOd,

I beg to differ.

You speak of NTP as a software emulation of a hardware device. You might 
have missed a point stressed in previous messages. While the 1588 
on-wire protocol is different than NTP, both use the same t1, t2, t3 and 
t4 timestamps and the same offset and delay calculations. The 1588 
calculations are done in the software driver or even by a utility 
program interfaced via USB(!) The actual math could in principle be done 
entirely using hardware chips, but that wouldnt really change anything.

The only real difference between 1588 and NTP is that 1588 defines a 
capture point on the media itself. If you stand back and look at it, 
this doesn't really matter for the same reasons as in NTP. In both 
protocols the object is to synchronize a slave clock in a kernel or NIC 
to a master clock in another machine, so the same arguments apply. The 
1588 capture point is specifically chosen to minimize jitter and so 
intervening switches can compensate for queueing delays. I don't think 
this detail belongs in the NTPv4 spec.

By intent, 1588 does not specify the nature of the feedback loop used to 
discipline the slave clock, but NTP does for the reasons discussed 
previously on this list and in the spec. The loop does not emulate 
hardware; it emulates an equation most often studied in control theory 
and digital signal processing textbooks. It is possible to implement 
these equations in hardware, software or a combination of both. DSP 
chips on the market today use both, as does your cellphone. NTP doesn't 
need hardware assist.

Dave

TS Glassey wrote:

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