On 2015-02-21, Rob <nom...@example.com> wrote: > William Unruh <un...@invalid.ca> wrote: >> On 2015-02-19, Rob <nom...@example.com> wrote: >>> Miroslav Lichvar <mlich...@redhat.com> wrote: >>>> On Thu, Feb 19, 2015 at 10:05:45AM +0000, Rob wrote: >>>>> We have systems in places that are not temperature controlled and then >>>>> chrony is much better. I am looking for the best way to find the >>>>> values to use in the tempcomp configuration directive. >>>> >>>> What resolution does the sensor have? Don't expect good results >>>> with 1C or 0.5C resolution that sensors on mainboards typically have. >>> >>> 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. >> >> It is of course the temperature of the crystal itself that is important. >> Ie, the room temp could be constant and the computer varies in its >> workload and thus its internal temperature. Unfortunately temp sensors >> on the crystal are rare in commodity computers. > > I am not looking for a precise crystal temperature but for a ballpark > value that will compensate for the quick temperature swings that occur > when this system (which is in an unheated glasshouse) quickly warms up > when the sun rises, and cools down when the sun sets.
It is the crystal temperature that determines the rate change. That crystal temp will be affected by the room temperature (with a lag since it it takes a while for the heat in the air to diffuse into the crystal--I have no idea how long that is, but is probably minutes rather than hours) how hard the machine is working (again the cpu heats up which eventually heats up the crystal) etc. One could probably use any of the temperature measurements that most motherboards have as proxies for the crystal temperature and get improved performance. Remember that the cpu temperature can vary by 20C which is probably more than the room does, and the motherboard forms a heat pipe from the cpu to the crystal. If you really want to study this, get a gps with a PPS and track the offset from the gps and one of those temperature measurements. You could switch off all clock discipline so that it cannot affect your measurements of rate as a function of temperature. Plot offset vs temperature. Look at the averaged slope of the curve to get a measure of how that temperature correlates with the rate. You could fit a curve (probably a quadratic in temperature would be fine.) Or run chrony or ntpd and plot the drift as a function of temperature with a low poll interval. chrony would probably be better in that it responds more quickly to changes in drift. (chrony has some tools for helping with this). Once you have measured this, you could use it in either the forks of ntpd which have temperature compensation, or with chrony. > > In ntpd these events result in offset swings that are the derivative > of the temperature. In chrony the swings are smaller, but it may be > deceptive because I have not yet found a completely satisfactory way > of gathering an "average offset" that is similar to the offset value > in ntpq -c rv. chrony's offset IS an average offset. It is fit to the past N measurements, where N varies depending on how good the linear fit is. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
