[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[Danny Mayer]

Brian Utterback wrote:
> 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.
> 

Contact Poul Henning-Kemp or Frank Kardel who did this for FreeBSD and 
NetBSD respectively.

Danny
> 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
>