[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[Brian Utterback]

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.

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