Richard B. Gilbert wrote: > > Ntpd is supposed to set it's own polling interval; something to do with > the "Allen Variance". My feeble understanding translates into English > as "short poll intervals allow ntpd to correct large errors quickly and > long poll intervals allow ntpd to correct small errors accurately". > > Anyway, I'm a little surprised that shorter is better. I have two > machines as clients of my stratum 1 (GPS) server. All three are Sun > workstations; the server is an Ultra 10 440 MHz, one of the clients is > also an Ultra 10 440 MHz the other is an Ultra 5 360 MHz. All have been > running for several days. The Ultra 5 is polling at 64 second intervals > with an estimated error of 11056 us while the Ultra 10 is polling at 256 > second intervals with an estimated error of 500 us. > > The proper poll interval appears to be highly dependent on the quality > of the local clock.
My experience is that shorter is better with commodity hardware that is subject to rapid thermal cycling - my home machines are in the basement which also houses the furnace - I can see the furnace 12 min on/off cycle in the frequency offset graphs. Equally when periodic compute intensive jobs run (one of my S1's is also a file/backup server) the resultant thermal shock to the machine pushes it way off - if I let ntpd poll long (or omit flag 3 on refclocks) it spends all it's time chasing the thermal cycle and never quite makes it. Will a poll of 64 (or less on my own servers) it catches it before it gets 250us off and corrects. My co-lo machines which have a much more even load and are in an cabinet in a machine room show a dinural cycle that ntp copes with pretty well even at a poll interval of 1024. John _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
