[ntpwg] ntpwg Updated NTPv4 ProtocolSpecification/timestamplocation

[TS Glassey]

----- Original Message ----- 
From: "David L. Mills" <mills at udel.edu>
To: <ntpwg at lists.ntp.org>
Sent: Sunday, February 03, 2008 11:57 AM
Subject: Re: [ntpwg] ntpwg Updated NTPv4 
ProtocolSpecification/timestamplocation


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

No... I cought the point.

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

But the question is one of how they use the same timestamps.  NTP is 
desinged to run in the OS context of some server. There are in fact NTP 
appliances, but they also suffer the same issues with the stack framing 
overhead and packet reception.

>  The 1588
> calculations are done in the software driver or even by a utility
> program interfaced via USB(!)

Depends whether they are executed by a FPGA or by an OS... Your push back is 
specific to one very particular type of 1588 device & there are others which 
are more appliance based.

The same can be said of NTP boxes from those embedded type systems which run 
on an integrated service. Others that are NTP Server's running on an OS 
context are 'emulators' by the very definition.

> The actual math could in principle be done
> entirely using hardware chips, but that wouldnt really change anything.

But doing the math in HW and the Network Interface in HW would 
significantly.

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

OK OK - but then the reality is that we need a performance specification for 
a minimum NTP or 1588 performance model and then in that case the frame 
point on the packet becomes relevent.

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