On 2012-02-25, Richard B. Gilbert <rgilber...@comcast.net> wrote: > On 2/25/2012 2:31 AM, David J Taylor wrote: >> "unruh" <un...@invalid.ca> wrote in message >> news:l9S1r.3578$py5.1...@newsfe09.iad... >> [] >>> The problem is that the relevant temperature is not the room >>> temperature, but the temperature inside the box at the crystal. That >>> temp variation is dominated by computer use, not outside air >>> temperature. Thus if one machine was coasting along, and the other was >>> working flat out, the temp variation witll be 10s of degrees C, even if >>> the outside air temp was constant. >> >> Yes, the computer use is important, but the PCs I have as prime >> startum-1 servers have a constant load, so the variation in room >> temperature dominates. >> >>> Also, different crystals have different sensitivities, it is true. >>> Anyway ,my comment stands that his 500PPM was not because of tempreture >>> problems. >> >> Yes, it's one I did not disagree with. What was remarkable to me was >> that, given a constant load, three different PCs showed such a variation >> in frequency. One with about 2 ppm, one with 0.3 ppm, and one with 0.025 >> ppm. All crystals are not created equal! >> >> [] >>> On linux of a few years ago (I do not know if it has been fixed, but >>> indirect observations suggests it has) the calibration of the system >>> clock at bootup was problematic and the rate of the system would vary by >>> 100PPM from one bootup to the next. Ie, ntpd would find its remembered >>> clock rate out by 100PPM. It would then take many hours to settle down >>> to its usual us offsets. (see graph near the bottom of page on >>> www.theory.physics.ubc.ca/chrony/chrony.html). This was driving it from >>> a GPS PPS clock with a poll level of 4. With a poll level of 6 to 10 for >>> a network server, the time scale will be longer by a lot (in fact it >>> would probably exceed the 500PPM limit and also suffer steps in the >>> clock as it exceeded 128ms offset). >>> >>> That yours settled down quickly in your situation does not mean that >>> ntpd always settles down nicely and quickly. >> >> Well, I've not seen the behaviour you observed, on any on my FreeBSD or >> Windows systems. The ntp.drift file is honoured at startup, and not >> tampered with until NTP has been up for one hour. Perhaps if you were >> repeat your test with a more modern NTP and operating system you would >> get a different result? But I don't think that anyone is claiming that >> you will get microsecond-level offset within minutes of operation from >> boot. >> > > Get ready for a shock. NTPD needs thirty minutes or more to get a > reasonable facsimile of the correct time. To get the microseconds > right, NTPD needs more like ten hours! It's not a very good fit for > running 9AM to 5PM. You set it running and leave it running 24x7! > > If you are constrained to run 9:00AM to 5:00PM you may wish to check out > a program called "CHRONY" or something like that. It has much faster > convergence. I suspect that you will sacrifice something for that speed!
Yes, you sacrifice inaccuracy. (ie chrony is also more accurate than ntpd, especially if temperatures change.) And you sacrifice being able to run it under Windows (it has not bee ported to Windows). > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
