[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    [ntp:hackers] NTP interleaved mode
From:       "David L. Mills" <mills () udel ! edu>
Date:       2008-06-04 17:39:50
Message-ID: 4846D366.7050905 () udel ! edu
[Download RAW message or body]

Guys,

Some time back I proposed a method with with NTP could do something like 
the IEEE 1588 two-step protocol, where the transmit timestamp is 
captured in hardware and transmitted to the client in a following 
packet. The mechanics of the timestamping process itself is explored in 
a white paper on the NTP project page previously announced. The paper 
was written to help resolve the issue of how to define how timestamps 
are struck in the NTPv4 specification.

I've worked out the details on how to do this as an option in NTP 
without changing the packet header format. It is done using an 
interleaved approach which takes two basic rounds to deliver two sets of 
timestamps. While the timestamps are delayed for two rounds, the overall 
rate of timestamps is the same as the basic protocol and the symmetric 
model is preserved. In addition, the protocol is backwards compatible 
and automatically adapts to the basic or interleaved modes, so current 
peers won't notice any change.

The protocol makes sense only for symmetric modes, as state must be 
preserved at least for the transmit timestamp. While it recovers from 
lost, duplicate or bogus packets, the recovery is not a smooth as in 
basic mode. Largely for that reason, it is most suitable for fast LANs 
and relatively small poll intervals. It is not intended as an 
alternative to 1588, but it has potentially comparable accuracy. My 
objective is that it could provide performance equivalent to the PPS 
signal as used today.

There is a white paper and briefing on NTP On-Wire Protocols on the NTP 
Project Page at www.eecis.udel.edu/~mills/ntp.html. In addition, there 
is a simulation tool program that can be used to explore behavior under 
various normal and error conditions. Comments would be relished. The 
protocol is simple and requires only a couple of additional state 
variables, but truly intricate. If you are interested and challenged, 
figure out how to avoid a protocol reset when a peer sends more than one 
poll during a single round, which can happen is symmetric modes.

Dave
_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]