Bill,
All my measurements were in temperature-controlled environments, such as
a campus lab or home office, and the data were collected over one week.
The temperature varied less than a degree C. However, I have data from
Poul-Henning Kamp for a similar experiment done in summertime Denmark
where the environment was not controlled. As expected it looked
something less than shown by the graph attached to my previous message.
The Allan characteristic tends to fizzle out at lags greater than about
one-fourth the span of the measurements. Thus, if you collect samples
for only one day the maximum lag could not be more than a few hours and
the diurnal effects would not be apparent.
A previous message implied that, once the Allan characteristic was
determined, it would show chrony to be better than ntpd. Be advised the
default time constant (at 64 s poll interval) was specifically chosen to
match trace 1 on the graph mentioned above. In other words, it is in
fact optimum for that characteristic and chrony can do no better.
Having said that, modern machines are faster and with less phase noise,
although with the same rotten clock oscillator. Thus, I would expect a
modern machine to behave something like trace 3 on my plot, where the
intercept is more like 200 s than 2000 s. From anecdotal evidence, 16 s
is about right, but 8 s is too vulnerable to jitter in the Ethernet NICs
and switches. NIC jitter can vary widely, even using the same Ethernet
chip, specifically the PCNET chips that do scatter-gather on-fly and
coalesce interrupts. I have measured jitter components from 150 ns with
a i386 running FreeBSD to over 1 ms with a Sun Ultra running Solaris
10. So, any performance comparisons must take these differences in account.
Dave
unruh wrote:
On 2010-09-10, Miroslav Lichvar <[email protected]> wrote:
Hi,
I'm trying to find out how a typical computer clock oscillator
performs in normal conditions without temperature stabilization or a
stable CPU load and how far it is from the ideal case which includes
only a random-walk frequency noise.
A very useful statistics is the Allan deviation. It can be used to
compare performance of oscillators, to make a guess of the optimal
polling interval, whether enabling ntpd daemon loop to use FLL will
help, how much better chrony will be than ntpd, etc.
If you have a PPS device and would be willing to run the machine
unsynchronized for a day, I'd like to ask you to measure the Allan
deviation and send it to me.
I wrote a small ncurses program that can be used with LinuxPPS to
capture the PPS samples and create an Allan deviation plot. An
overview is displayed and continuously updated while samples are
collected. Data which can be used to make an accurate graph (e.g. in
gnuplot) are written to the file specified by -p option when the
program is ended or when the 'w' key is pressed.
Available at:
http://mlichvar.fedorapeople.org/ppsallan-0.1.tar.gz
Obligatory screenshot :-)
Allan deviation plot (span 11:09:55, skew +0.0)
1e-05???
???
+
???
??? + +
1e-06??? +
??? +++
??? ++
??? +++
??? ++
1e-07??? +++
??? ++
??? +++
??? ++ ++++++
??? +++ ++++
1e-08??? +++++++++
???
???
???
???
1e-09???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
1e+00 1e+01 1e+02 1e+03 1e+04 1e+05
w:Write q:Quit r:Reset 1:Skew 0.0 2:Skew +1.0 3:Skew -0.5
To make a good plot:
1. disable everything that could make system clock adjustments
2. start ./ppsallan -p adev.plot /sys/devices/virtual/pps/pps0/assert
(change the sys file as appropriate)
3. let it collect the PPS samples for at least one day
4. hit q and send me the adev.plot file
Thanks,
Except yo uknow that the typical computer clock is driven mostly by
temperature variations, and those are time of day dependent. People tend
to work during the day thus their computer works during the day, and
does not at night. Ie, there is a very strong daily cycle in the temp of
the computer. That is NOT within the Allan model, and the Allan
variation and minimum are really irrelevant with this highly
non-stochastic noise model.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
