On 02/11/2015 10:01 AM, Rob wrote:
> Terje Mathisen <terje.mathi...@tmsw.no> wrote:
>> The 500 ppm limit is not at all arbitrary!
>>
>> In fact, it was originally just 100 ppm, but when too many systems
>> turned up with a system clock which was a bit too far out, Prof Mills
>> redid the control loop to allow a 500 ppm range.
>>
>> It could have been a lot more, but the ultimate stability of the control
>> loop is supposed to be better this way.
>
> I think it is hogwash. The static drift cannot have any influence
> on the stability of the control loop. A static drift is just a frequency
> error that is determined once and can then be forgotten about.
The limit is said to be required in the original mathematical proof of
the stability of NTP networks. Unlike the typical setup today, this
included *fully meshed* networks of nodes *peering* with each other,
with ample potential of feedback loops through several of them leading
to oscillation.
(Disclaimer: I never found it necessary to verify, or even read, the
math myself.)
> I remember that in the past sometimes a specific adjtime command was
> used to pre-configure a static error so that ntpd would not see it.
> No idea if this still works.
At least on the (Linux) systems where I found it necessary to use it to
counter a bad clock, changing the tick value has worked so far. (Bar one
stone-age busybox-based server where the devel environment had been lost
in time and nobody could compile tickadj or any other tool that'ld allow
me to touch tick in the first place.)
Note that the default value of tick on Linux boxen is 10000, so changing
this integer value by one theoretically effects a 100 PPM shift. (For
whatever reasons, my practical experience is more like 120 to 150 PPM
...) There's your valid reason why raising the NTP limit from 100 to 500
made more sense than raising it further to 5000 or whatever.
However, I've also seen hardware occasionally flip-flopping from -900 to
+1100 and back, complete with the developers of the firmware blaming "a
bug in ntpd" for failure to discipline *that*. Would I want ntpd to
cater for such cases? Heck, no. It would *never* be able to keep *that*
clock in sync to the quality standards of proper NTP servers, and
"standard tools *refuse* this pile of clockwork rejects" provides the
push to the only *proper* solution, namely, to fix the hardware.
Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
