Unruh <[EMAIL PROTECTED]> wrote: > Actually it is much worse than that. On my system, on bootup the clock > frequency can very by up to about 50PPM due to a Linux bug. In general it > takes ntp about 10 hours to regain tight synchronisation. (In that case it > is microsecond since it is synching to a GPS, but it is also on poll level > 4 so it has lots of data and should converge faster than some other system > on poll level 6-10). David Mills has always insisted that ntpd is designed > for stable long time operation, and rapidity of response is a distant 49th > or so in priority. >
Which linux bug causes your frequency to vary? The only frequency issue I've encountered is a slight variation in the dynamic boot time measurement of the TSC (time stamp counter) frequency. This problem is not so much a bug in my opinion and is easily fixed by changing the clock source to something other than "tsc". In our system, we chose to use acpi_pm, which so far has shown no frequency variance. If this isn't the issue you are having, I would be interested in which bug you have that causes frequency variance. Andy _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
