[ntpwg] Updated NTPv4 Protocol Specification/timestamp location

[David L. Mills]

Stuart,

The Unix semantics provides only the gettimeofday() (or equivalent) 
system call to implement a capture point. As an implementation issue, 
best practice is make the capture points as close to the media as 
possible. For instance, the reference implementation captures the 
receive timestamp before buffering the packet and compensates for the 
message digest computation for the transmit timestamp. This is the best 
we can do considering the Unix semantics. To require otherwise is an 
exercise in futility.

I've said that NTP does not tell the time, only the offset and related 
statistics of a remote clock relative to the local clock. I've also said 
this works well as long as the reciprocal delays are the same. The 
gettimeofday() can capture transmit timestmap shortly before the 
beginning of the on-wire frame and capture the the receive timestmap 
shortly after the end of it. As long as the queuring delays are small 
and the transmit and redeive frames the same length, the reciprocal 
delays are the same. That's the best that can be done. Everything else 
is minimizing the queueing delays and there is nothing that can be 
required in the specification about that.

Now, propose an addendum to the specification or a new specification. 
Call it timestamping on steroids and have it usable by other protocols 
like 1588 as well. There are two possible seriods called driver steroids 
and media steroids. With driver steroids the driver captures a timestamp 
as soon as possible after a frame has been transmitted or recieved, 
perhaps using the PCC or TSC. The reason I choose the end is to to 
chooose only the last in a series of possible retransmissions. This is 
not as simple as it seems. Modern NICS have transmit and receive buffers 
as well as a 16K FIFO that can be shared for both transmit and receive. 
To capture an accurate timestamp, the driver has to keep track of which 
user-supplied packet has just completed and how to get the timestamp 
back up the stack to the user.

With hardware steroids the timestamp is captured by the hardware, but 
the remaing operations are the same. In this case it is the first bit 
following the SOF and avoids the FIFOs. With what 1588 NICs Ican find, 
the timestamp precision is in the order of 50 ns. This option is 
expensive; 1588 NICs cost upwards of $600.

I still have a shoe to drop. Once one or both of the above steroids have 
been injected, NTP needs a new two-step feature as described in the 
archtecture briefing on the NTP project page. The two-step feature 
operates much like 1588 and could be made compatible with the existing 
one-step protocol. This would, in principle, provide performance limited 
only by the NIC.

I need to emphasize that the on-time considerationa have nothing to do 
with which bit in the frame, packet or header is chosen; that makes no 
difference. The only importance is the differential delays on the 
reciprocal paths and the degree to which delay variationis can be 
suppressed. To the degree these things cannot be controlled by the 
implementation, they should not be in the specification.

Dave


(STUART VENTERS wrote:

>>> Dave said:
>>> There may be a fundamental disconnect happening here.
>>
>
> Dave,
>
> We appear to be in agreement that in order to interoperate, a client 
> and host must implement 'capture point' such that the end to end 
> reciprocal delays match. (Or in other words, if the client and server 
> clocks are aligned then T2-T1 must match T4-T3).
>
> I think I see the disconnect.
>
> In your last paragraph, there appear to be 2 meanings to the term 
> 'capture point'.
> CP1 = Which bit transition in the packet to strike timestamps against. 
> Like SOF or NTP header.
> CP2 = The location in the host where the packet time is measured. Like 
> near the Phy or not.
>
> (These 2 issues are so tightly coupled that one might want to keep 
> them together, but I think to doing so clouds things.)
>
> Also, your first 2 paragraphs say to me that CP1 and CP2 don't matter 
> as long as the reciprocal delays match. I agree with this if you goal 
> is to build client/server pair that work together. I disagree if the 
> goal is to make a spec so anybody can build either end.
>
> I agree that the fundamental constraint is that the reciprocal delays 
> match, but there are many non-interoperable ways for a working 
> client/server pair to skin this cat. The NTP spec needs to further 
> limit the choices so that any combination of complying implementations 
> will interoperate. On the other hand the spec does not need to 
> unnecessarily constrain or burden the implementation. (Simple rules 
> would also be nice.)
>
> I don't pretend to know the best way to do this, but one way might be 
> to state the fundamental constraint so everybody knows what we are 
> trying to accomplish, then specify choices for CP1 and CP2 as the 
> chosen way to achieve the constraint, and then add a sentence which 
> says that any host which has equivalent behavior (except maybe with a 
> different symmetric link delay added) is also ok.
>
> For CP1, I disagree that "this is not an NTP issue at all". Nailing 
> down CP1 will go a long way towards satisfying the fundamental constraint.
>
> For CP2, we could choose at the external media connector on the host. 
> (Which is of course non-implementable, but still useful with the 
> equivalent behavior clause.)
>
>
> Regards,
>
> Stuart Venters
>
>
> My agenda:
> The NTP spec needs to set tight enough rules so that any 2 
> implementations, meeting the rules will interoperate. (I.E. transfer 
> accurate time.)