[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

David L. Mills mills at udel.edu
Fri Feb 22 21:48:16 UTC 2008


Greg,

Just getting a timestamp on the last packet sent might not be enough, as 
there may be several packets queued behind it. There needs to be a way 
for ntpd to associate the stamp with the relevant association. There 
probably also need a way for the output driver to recognize what packets 
should be stamped.

Excuse me while I dust off 30 years from my first TCP implementation. 
For historic and hilarious reasons we had something called rubber-EOL, 
since then wisely deprecated, and something called the urgent pointer. 
Reason was to provide an interrupt capability something like the 
red-ball/green-ball scheme implemented in TYMNET. I implemented it in 
the Fuzzballs to avoid the nasty delay between jamming the BREAK key and 
waiting for several second before the data in the pipe emptied. I don't 
think that has been deprecated, even if the need for it is probably not 
still with us.

I drop the other foot. Did I read somewhere that the Unix I/O system 
still hasthe  ablity to read out-of-band (OOB) data? That would be 
necessary to volley the balls. If such still be the case, why not have 
the output driver snatch the pseudo header of the last transmitted UDP 
packet, stick it and timestmap in a buffer and shoot up the OOB 
function? There still needs to be a socket bit to enable the function.

Dave

Greg Dowd wrote:

> What I did in linux was extend the socket buffer to add a tx timestamp
> and then used ioctl to query. It's pretty lame as there is no
> correlation other than socket, just last tx. Best way would be to
> reflect the pkt back into the receive queue with that timestamp. I've
> played with this in my ethernet driver but I don't know how to make the
> kernel do it automagically in linux.
>
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
> Brian Utterback
> Sent: Friday, February 22, 2008 10:23 AM
> To: M. Warner Losh
> Cc: ntpwg at lists.ntp.org; stuart.venters at adtran.com
> Subject: Re: [ntpwg] ntpwg Updated NTPv4 Protocol
> Specification/timestamp location
>
> I meant the *transmit* interrupt. How do you get the timestamp back to
> ntp and how does ntp relate the timestamp to the packet?
>
> M. Warner Losh wrote:
>
>> In message: <47BF0F5C.8060405 at sun.com>
>> Brian Utterback <brian.utterback at sun.com> writes:
>> : I seem to recall that there is an implementation in FreeBSD to
>> : get the transmit interrupt timestamps. Is anybody here familiar
>> : with how that was implemented? I talked to some Solaris interface
>> : driver writers and they seemed to think that it was not practical.
>>
>> It all depends on your hardware and what performance hit you want to
>> take with the newer, more sophisticated hardware.
>>
>> The way it is implemented in FreeBSD is geared more towards older,
>> simpler hardware. The time of the interrupt is recorded on the theory
>
>
>> that it will be more or less constant between when the packet arrives
>> and when the interrupt happens. This works well on old hardware, but
>> newer hardware falls down badly since interrupts are deferred,
>> offloading happens, etc.
>>
>> Warner
>>
>> : STUART VENTERS wrote:
>> : > Kurt:
>> : >
>> : > Thanks for the support. In the notes Dave published, checkout the
>> : > section titled 'Errors Due to Interworking Between Software,
>> Hardware,
>> : > and Driver Schemes' and see if it addresses your test case.
>> : >
>> : > _http://www.eecis.udel.edu/~mills/timestamp.txt_
>> : >
>> : >
>> : > As you can see, Dave and I are now pretty much in agreement with
>> the
>> : > analysis. Hopefully it can morph into an appendix to the NTP
>
> spec.
>
>> : >
>> : > The notes describe a variety of timestamping schemes and shows how
>
>
>> they
>> : > interoperate. The simplest scheme (called hardware) uses
>> timestamps at
>> : > the start of packet. This is the scheme the 1588 spec and
>> hardware
>> : > support. Another scheme (called software) uses tx timestamps at
>> the
>> : > start of packet and rx timestamps at end of packet. This is the
>> scheme
>> : > used by the reference NTP implementation, and I suspect also the
>> one
>> : > which interoperates best with vanilla switches and routers.
>> : >
>> : > My main goal in this discussion was to get some specific scheme in
>
>
>> the
>> : > spec so that as implementations get more precise, they will
>> continue to
>> : > interoperate. The notes propose a single scheme (hardware) that
>> : > implementations should use for interoperability. This meets my
>> original
>> : > goal and I'm ok with this choice on the grounds that it is simple.
>> : >
>> : > An unexpected outcome in the discussion was that the simple choice
>
>
>> that
>> : > 1588 made was not optimal for some cases without on-path support.
>
>
>> The
>> : > software scheme, appears to sometimes offer better accuracy.
>> : > Unfortunately, it's also more complex and different. I'm torn
>> between
>> : > the simple hardware scheme and a slightly weird software scheme
>> which
>> : > should work better with existing implementations and on paths
>> without
>> : > on-path support. (Note that this is not a question of what
>> measurement
>> : > means are available, because the implementation can transpose from
>
>
>> one
>> : > scheme to another.)
>> : >
>> : > As I said before, I can live with the choice of the hardware
>> scheme
>> : > (SOPtx, SOPrx), but am curious as to how the group feels about the
>> : > software scheme (SOPtx, EOPrx).
>> : >
>> : > Regards,
>> : >
>> : > Stuart
>> : >
>> : >
>> : > It looks like the analysis Dave published 21st,
>> : >
>> : > Kurt Roeckx wrote:
>> : > > On Thu, Feb 07, 2008 at 05:34:08PM +0000, David L. Mills wrote:
>> : > >> Stuart,
>> : > >>
>> : > >> No, compare your equation with mine. The view has to be from
>> A, so the
>> : > >> delay cancels.
>> : > >
>> : > >
>> : > > I'm still not convinced. So I'll try to make an example.
>> Let's assume
>> : > > that it takes 2 second for the packet to travel from A to B and
>
>
>> the
>> : > > other way around. That is, if A sends a physical signal from
>> low to
>> : > > high, B will see that change 2 seconds later. Let's also
>> assume that it
>> : > > takes A 1 second to transmit the packet. Then let's assume
>> that A's and
>> : > > B's clock are in sync, and that A takes the timestamp at the
>> start of
>> : > > the packet, and B and the end.
>> : > >
>> : > > We start with A sending a packet at time 0.0. A takes the time
>> : > > when the packets starts to be transmitted, so sets T1 to 0.0.
>> : > >
>> : > > The packet will start to arrive at B at 2.0, and stop at
>> : > > 3.0. B takes the timestamp at the end of the packet
>> : > > and will set T2 to 3.0.
>> : > >
>> : > > It takes B 1 second to process the packet. It will start to
>> transmit
>> : > > the packet at 4.0. But since it timestamps the packets after
>> : > > it's completly send, it will set T3 1 second later to 5.0. B
>> will
>> : > inform
>> : > > A about T3 with an other packet it will send later.
>> : > >
>> : > > The packet starts to arrive at A at 6.0, which is when A takes
>> : > > the timestamp, getting us T4 = 6.0. The packet completly
>> arrives at
>> : > > 7.0, but that doesn't matter.
>> : > >
>> : > > This gives:
>> : > > offset = 1/2 * [(T2-T1) + (T3-T4)] = 1/2 * [(3-0)+(5-6)] = 1.
>> : > >
>> : > > While we expected the result to be 0.
>> : > >
>> : > > Note that for the delay we don't have the problem.
>> : > > delay = (T4-T1) - (T3-T2) = (6-0) - (5-3) = 4.
>> : > >
>> : > >
>> : > > Kurt
>> : >
>> : >
>> : >
>> ----------------------------------------------------------------------
>> --
>> : >
>> : > _______________________________________________
>> : > ntpwg mailing list
>> : > ntpwg at lists.ntp.org
>> : > https://lists.ntp.org/mailman/listinfo/ntpwg
>> :
>> : --
>> : blu
>> :
>> : There are two rules in life:
>> : Rule 1- Don't tell people everything you know
>> :
>> ----------------------------------------------------------------------
>> : Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
>> : Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
>> : _______________________________________________
>> : ntpwg mailing list
>> : ntpwg at lists.ntp.org
>> : https://lists.ntp.org/mailman/listinfo/ntpwg
>> :
>> :
>
>
> --
> blu
>
> There are two rules in life:
> Rule 1- Don't tell people everything you know
> ----------------------------------------------------------------------
> Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg




More information about the ntpwg mailing list