On 2/25/2012 2:31 AM, David J Taylor wrote:
"unruh" <[email protected]> wrote in message
news:[email protected]...
[]
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!
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
