[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[STUART VENTERS]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.org/pipermail/ntpwg/attachments/20080222/54fe85d8/attachment.html