[ntpwg] Updated NTPv4 Protocol Specification/timestamp location
David L. Mills
mills at udel.edu
Wed Jan 23 19:18:48 UTC 2008
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.
(STUART VENTERS wrote:
>>> Dave said:
>>> There may be a fundamental disconnect happening here.
> 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.)
> 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.)
More information about the ntpwg