[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Unruh unruh-spam at physics.ubc.ca
Fri Jan 25 18:00:33 UTC 2008


"David L. Mills" <mills at udel.edu> writes:

>Daivd,

>Well, I have done a market survey of sorts, if you can count my 
>consulting clients. There seems general agreement that 1 ms is a good 
>target, but there is a wide range of expecttions on how quickly that 
>must be achieved. Actually, if the TOY chip is within 1 PPM and the 
>downtime is less than 1000 s, convergence is essentially instantaneous. 
>My advice to the Aegis crew was to isolate the NTP puppies on the fire 
>control Ethernet and allow only a couple of other computers on the wire. 
>Crony would work just fine.

>Here's another contribution to the market survey. There is a seismic 
>network on the sea floor off the Washington state coast. They need a 
>millisecond for experiments lasting months, not just 8-hour shifts, and 
>that when the experiment boxes get rather warm. Crony might work here as 
>well, but it would have to track large swings in temperature.

>Here's another one. National Public Radio (NTP) distributes almost all 
>program media via IP and digital satellite. They don't need 1 ms, but 
>they do need good stability in the face of highly variable transmission 
>delays that could drive crony nuts.


Your evidence that it would drive chrony nuts is what?

>And another one. A transatlantic link used by Ford Motor was once a 
>statistical multilexor that interleaved terminal keystrokes on a 
>demand-assigned basis. Toss NTP packets in that mess and watch the huge 
>jitter. That not only drove NTP nuts, it drove the TCP retransmission 
>algorithm nuts, too.

And you tested chrony on this?




>Seems like the market is highly fragmented.

Sure. 



>I hear you say "100 ms" which I interpret as 100 milliseconds. Even 25 
>year old fuzzballs could to much better than that on the congested 
>ARPAnet. Did you mean 100 microseconds?

>Dave

>David Woolley wrote:

>> David L. Mills wrote:
>> 
>>> 5. This flap about the speed of convergence has become silly. Most of 
>>> us are less concerned about squeezing to the low microseconds in four 
>> 
>> 
>> Have you done the market surveys to confirm this?  I don't have the 
>> resources or time to do that, but my impression from the sort of 
>> questions that appear on this newsgroup is that most IT managers and 
>> turnkey system developers who want better than 100ms clock accuracy want 
>> one or both of:
>> 
>> - fast convergence (small compared with overall bootup time) - a
>>   a common case, these days, is that they are not allowed to process
>>   financial transactions until convergence is complete;
>> 
>> - strict monotonicity.
>> 
>> It may well be that most users don't need better than 100ms, but those 
>> users don't care about long term stability, and their long term may be 
>> an 8 hour shift.
>> 
>> 
>> (My interest in NTP is more theoretical, as I work in an industry sector 
>> that, whilst it deals with timestamped data, those timestamps are often 
>> a minute or two out (and are added by equipment that is out of our 
>> control), but I do notice the sorts of questions that keep coming up 
>> time and time again.)




More information about the questions mailing list