William Unruh <un...@invalid.ca> wrote: > No, that is a hardware solution. There are software solutions-- a > termistor to meaure the temperature of the crystal ( or somethign > nearby) which feeds that measurement to the OS. the revised ntp then > reads the temperature, and corrects the drift rate as a function of that > temperature. This means that the change in the ntpd drift rate does not only > depend on > the offset meaured but also on that temperature. Since it takes a while > for a temperature to be reflected in the offset, this makes ntpd track > the correct rate of the clock much more closely. Yes, factors of 5 are > easy. Actually, I suspect that oneof the reasons that chrony does so > much better than ntpd does in disciplining the clock ( 2-20 times > better) is because it reacts to such temperature changes much more > rapidly. It can do so because it keeps a memory of the drifts and > offsets and can see changes much more quickly. It also does not throw > away 85% of the measurements to correct round trip errors, so can also > react faster because of that.
After reading that chrony can now handle local PPS clocks, I viewed the recent chrony manual and I see that it has support for temperature compensation as well. Unfortunately it is not automatic so it will have to be calibrated and put in the configuration file. As described by others it would be possible to make it auto-calibrating and only save the results of the calibration like the drift that is also saved. Measuring the temperature is no problem, those systems have a couple of different temperature sensors (for ambient, board and CPU temperature) that can be used as an approximation. Maybe I try chrony. First I need to test it on my own system and see if it can be monitored similar to ntpd (readvar). _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
