>>> In article <o48hm.41192$ph1.17...@edtnps82>, Unruh >>> <unruh-s...@physics.ubc.ca> writes:
Unruh> So I have 9 clocks. The rates are -190, 19 , -106, -67,-200 -219, Unruh> -115 -140 221 Unruh> On reboot, the latter changed from 221 to 215 (Which took ntp about 6 Unruh> hours to recover from) Unruh> The clock scaling in linux seems to suffered a real problem in the Unruh> past year or two, so that the rate from one reboot to the next can Unruh> change by 50PPM, which then takes ntp a long time to recover from. Unruh> two years ago those same clocks, running earlier kernels, had rates Unruh> of 5 -17 45 27 23 100 101 -10 8 -39 39 25. Unruh> It will not take much more degredation for the clocks to surpass the Unruh> 500PPM limit. And this is not due to any change in the hardware. It Unruh> seems to be kernel software and the scaling calibration being Unruh> performed at bootup. So it looks like the problem is in the way your kernel is deciding the value of 'tick' at boot time. Why is it better to 'fix' this problem in ntpd instead of either fixing the kernel boot calibration or finding a way to override the kernel calibration routine's "wrong choice"? We really would prefer to keep bloat out of ntpd, and this problem, to me, should really be fixed closer to its source. -- Harlan Stenn <st...@ntp.org> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
