[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[Brian Utterback]

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