[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

Greg Dowd GDowd at symmetricom.com
Fri Feb 22 19:51:08 UTC 2008


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


More information about the ntpwg mailing list