[ntpwg] [ntpwg Updated NTPv4 Protocol Specification/timestamplocation
tglassey at earthlink.net
Mon Jan 21 19:43:46 UTC 2008
I have been meaning to ask - why this is necessary since what you are
betting on is the performance of the TCP/IP (or in this case the UDP/IP)
Stack, and since there are no performance metrics for it, that makes the
issue of which edge represents which point in time somewhat moot I would
----- Original Message -----
From: "STUART VENTERS" <stuart.venters at adtran.com>
To: <mills at udel.edu>
Cc: <ntpwg at lists.ntp.org>
Sent: Monday, January 21, 2008 9:31 AM
Subject: [ntpwg] [ntpwg Updated NTPv4 Protocol
>>From the Dec 13 minutes it looks like they chose a timestamp location.
>>It's different, but maybe a good compromise (notes below). Except for
>>lacking text specifying the new location and how to know if the message
>>uses the old or new plan, do you feel it still needs to be on the stove or
>>is it nearly soup?
> (Perhaps soup, when the text shows up.)
> David L. Mills wrote:
>> Your meeting minutes said that some aspects of the timing point issue
>> were not discussed. From the absence of the point I made, I assumed that
>> point had not been discussed. In any case, I am glad the issue is still
>> on the stove and is to be resolved.
> Karen's Dec 13 meeting notes:
>>>* Text is still lacking that clearly defines which bit in the packet
>>>the timestamp represents. The WG needs to decide on the
>>>precise approach. Three options were discussed:
>>>a) The timing bit be the first bit of the IP packet or
>>>b) the timing bit be located at the beginning of NTP payload or
>>>c) Use the start of the Ethernet frame.
>>>Discussion: The timestamp should reference the start of the
>>>NTP header. Yaakov Stein, Stewart Bryant, and Greg Dowd to
>>>work offline and submit proposed text.
> Didn't get to hear the discussion, but it looks like the start of the NTP
> header was chosen.
> It seems doable with 1588 measuring H/W if the S/W does a correction to
> move the timestamp to the NTP header start. (Compensating for 42 bytes of
> header on a 10Meg link might cost 10 nS of uncertainty if the Ethernet
> clock is off by 300ppm. Faster links have less uncertainty.)
> There may be an existing versus new implementation interoperability issue
> if one end uses start of packet and the other uses start of NTP. (Looks
> like a 3us time offset for a 100Meg point to point link, correctable if
> the S/W knows about it. Could be ignored or fixed in the new
> implementation with negotiation or configuration.)
> On non point to point packet paths, it probably depends on the link speeds
> and header sizes on the intermediate links and the forwarding behaviors of
> the intermediate boxes. Hopefully if the client and server have the same
> kind of links and the forwarding behaviors are symmetric, then it will all
> cancel out. If the client and server have different link speeds, then
> putting the timestamp near the middle of the packet nearly cancels out the
> timeoffset. Without knowing the exact forwarding behavior of the
> intermediate boxes, this seems a reasonable compromise.
> ntpwg mailing list
> ntpwg at lists.ntp.org
More information about the ntpwg