I admit that I have not looked at the chrony code/doc and do not use it as it when I did take a look, it had no ref clock support so I don’t know what the objective is here. That said, from the current discussion I have a feeling that integrating temperature data into the clock control loop is not the right use for that info. Where frequency stability is paramount as in quartz/rubidium frequency standards which have stability 2 or more orders of magnitudes better than any cpu system clock, none of those use temperature data in their control loops and for good reason. The only instance where it could possibly be useful, but where there are no commercial implementation AFAIK would be where a 1PPS ref was lost. Use temperature date by all means, but use it to control the environment and not the loop, for what you are measuring with the clock offset is the result of the total perturbations on the system, temperature being the most important in the short term. With a modern cpu, chip temperature, for which you can get data has extremely erratic and rapid swings according to load. Trying to follow those is unlikely be productive as you have recognized .
"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin > Le 19 févr. 2015 à 15:18, Miroslav Lichvar <[email protected]> a écrit : > > On Thu, Feb 19, 2015 at 12:48:46PM +0000, Rob wrote: >> I am still finding out what sensor is best to use, we do have a room >> temperature sensor that has .1C resolution and is readable via snmp, >> and there are the usual sensors for board- and inlet air temperature. >> (and of course CPU temperature) >> >> It does not matter if it is only a course indication, the room temperature >> varies over a -10 .. 50C range (don't ask...) and a 1C resolution is not >> bad relative to that. > > In my tests using a sensor with 1C resolution it was barely useful > with NTP sources and 1024s polling interval. If the sensitivity is > around 0.1 ppm per degree, 1C resolution means the compensation > jumping the frequency in 0.1ppm steps. That's a lot, especially if you > compare it to the tracking skew with a refclock. > > I'd probably try a shorter polling interval first and maybe get a PPS > with higher rate if possible to minimize the swings due to temperature > changes. > > -- > Miroslav Lichvar > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
