[ntp:hackers] loopstats log - Allan deviation truncated decimal places?

David L. Mills mills at udel.edu
Fri Jan 7 20:43:13 PST 2005


Mark,

Should somebody care to believe it, your apparent clock stability is 
better than a cesium clock (stability better than 10e-12). What you are 
seeing is random noise and not suitable as a performance metric. Note 
that the data are collected prior to the phase discipline, which reduces 
the wiggle by 256 at 16-s poll. In other words, what you are seeing is a 
huge lowpass filter on the real oscillator wiggle. These are not 
meaningful statistics.

Sigh. I'll put the misleading field width back in as long as you don't 
claim the values truly represent the real clock stability.

Dave

Mark Martinec wrote:

>>Mark Martinec wrote:
>>
>>>I noticed my recent loopstats logs show only three decimal places
>>>for the sixth field (next to last)  in loopstats log, ...
>>>There used to be 6 decimal places in my earlier logs,
>>>and the web page shows example with 7 decimal places: ...
>>>I think adding back two or three decimal places makes more sense
>>>on the plot, although I'm not arguing if these additional decimal places
>>>may or may not be significant.
>>>
>
>>From Dave:
>
>>This was purposely done, as the digits below 10e-9 are meaningless in a
>>nanosecond clock. The precision corresponds to the frequency precision,
>>which is also 10e-9.  The former representation was 10e-12, which is
>>ludicrous. The implication is that what you see below 10e-9 is
>>significant only if you pretend a picosecond clock. You will note the
>>value sometimes appears at .000, which is also intentional and tells
>>you that the Allan deviation estimate is probably more affected by the
>>noise floor than valid measurements.
>>
>
>It is always 0 with a GPS clock.
>
>
>>It's really important in this 
>>business to avoid drawing conclusions from what is really
>>fourserbaliwhiganoi*.
>>
>
>Hmm, now that I switched from playing with a LW radio clock
>back to a true GPS receiver (Trimble Acutime 2000 / Palisade,
>with the advantage of the brand new Dave's one-second timer routine
>in the transfer vector, on an oldish 1.5 GHz AMD / FreeBSD with a
>clock granularity of about 120 ns (kern.timecounter.hardware=TSC) ),
>I had to extend the loopstat fields #4 (freq) and #6 (allan) to see
>any change at all in the plots:
>
>ntpd/ntp_util.c:
>- fprintf(loopstats.fp, "%lu %s %.9f %.3f %.9f %.3f %d\n",
>+ fprintf(loopstats.fp, "%lu %s %.9f %.5f %.9f %.7f %d\n",
>
>53378 3595.448  0.000000020 75.29634 0.000000158 0.0000037 4
>53378 3611.449  0.000000492 75.29634 0.000000273 0.0000032 4
>53378 3629.451  0.000000017 75.29634 0.000000335 0.0000028 4
>53378 3644.452  0.000000532 75.29636 0.000000388 0.0000080 4
>53378 3661.444  0.000000328 75.29636 0.000000351 0.0000069 4
>53378 3677.445  0.000000145 75.29636 0.000000317 0.0000060 4
>53378 3692.446  0.000000092 75.29636 0.000000276 0.0000052 4
>53378 3709.448  0.000000100 75.29636 0.000000239 0.0000045 4
>53378 3725.449  0.000000113 75.29636 0.000000207 0.0000039 4
>53378 3742.451  0.000000118 75.29636 0.000000180 0.0000034 4
>53378 3758.452  0.000000108 75.29637 0.000000156 0.0000082 4
>53378 3775.453  0.000000079 75.29637 0.000000135 0.0000071 4
>53378 3791.445 -0.000000061 75.29637 0.000000137 0.0000061 4
>53378 3808.446 -0.000000089 75.29637 0.000000119 0.0000053 4
>53378 3826.448 -0.000000102 75.29636 0.000000103 0.0000089 4
>53378 3842.449 -0.000000180 75.29636 0.000000098 0.0000077 4
>53378 3859.451 -0.000000170 75.29636 0.000000085 0.0000067 4
>53378 3877.452 -0.000000110 75.29636 0.000000079 0.0000058 4
>53378 3893.444 -0.000000165 75.29636 0.000000074 0.0000050 4
>53378 3910.445 -0.000000191 75.29636 0.000000065 0.0000043 4
>53378 3925.446 -0.000000380 75.29634 0.000000110 0.0000085 4
>53378 3940.448 -0.000000353 75.29634 0.000000097 0.0000074 4
>
>The plot of offsets and relative frequency look very nice,
>most of the time the offset stays nicely below +- 1 microsecond.
>
>Is it just me that expects too much? What about all the
>*real*guys* with caesium clocks and ovenized xtals in PCs?
>I guess they just play with real tools and not toy with PCs :)
>
>  Mark
>




More information about the hackers mailing list