Richard B. Gilbert wrote:
thanks Richard
Jim Cromie wrote:
wrt linux kernel patch
Ive been logging its 'performance' thru a dumb little script:
while true; do
echo
uptime
ntpq -p
having read some recent posts, Ive changed that to -pcrv
snip
It looks a lot like the offset,jitter fields step only when the when
field rolls over,
thus it looks like an artifact, is that a correct inference ?
Your offset and jitter fields are recalculated at each poll interval.
You are polling every 1024 seconds so it takes about 17 minutes to get
new values. The fact that you are polling at 1024 second intervals
suggests that ntpd is very satisfied with its selected soure(s).
In addition, Id like to use the /var/lib/ntp/ntp.drift
to compute a correction for the free-running frequency Ive told the
driver
about the crystal. Is that possible / sensible / wise ?
Ntpd will correct the frequency as long as it's running. If it loses
contact with its time source(s) it will continue to use the last value
it calculated.
Let me re-explain what Im after.
I could shutdown ntpd, and let the hardware timer free-run.
Id expect the frequency to go its natural way, so without the correction
under lock,
it would end up with a different time, and I could compute PPM error
from the duration and the diff.
Ive told the clocksource driver that the hardware is a hires timer at
1.000000 Mhz, which is
somewhat inaccurate. I want to add/subtract some tiny amt so that when
the free-running
hardware timer, driven by a crystal, rolls over, its treated as
X+epsilon nanoseconds,
not just X
Id rather not wait 12 hrs to get a reasonably accurate number,
so Id like to take some number (the 'correction') from ntpd itself and
compute the free-run freq
from it. One of the numbers in the ntpd state represents the frequency
correction.
22:27:49 up 44 min, 2 users, load average: 0.00, 0.00, 0.00
remote refid st t when poll reach delay offset
jitter
==============================================================================
*harpo 216.82.75.146 3 u 22 128 377 0.865 10.913
9.481
+ns2.pulsation.f 194.2.0.28 3 u 73 128 277 114.431 -0.829
66.063
LOCAL(0) LOCAL(0) 13 l 21 64 377 0.000 0.000
0.004
assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd [EMAIL PROTECTED]:4.2.0a+stable-8-r Fri Oct 28 15:39:49 CEST 2005
(1)"?,
processor="i586", system="Linux/2.6.17-rc3-mm1-hrt-clksrc-sk", leap=00,
stratum=4, precision=-18, rootdelay=96.293, rootdispersion=325.746,
peer=19036, refid=192.168.42.1,
reftime=c809553f.94e9c454 Sun, May 7 2006 22:27:27.581, poll=7,
clock=0xc8095555.ec17ebaf, state=4, offset=3.527, frequency=0.352,
noise=18.505, jitter=15.091, stability=555.907
and I just found this.
http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP
cat /var/lib/ntp/ntp.drift
-46.177
While Im asking, does anyone here know where pics/graphs of rms
jitter energy vs freq
are available for a variety of timing-sources, including those that
show up in PCs
and server boxes.
Does the jitter number on
LOCAL(0) LOCAL(0) 13 l 17 64 377 0.000
0.000 0.004
have a real meaning wrt the frequency noise in the PC's clock ?
The jitter, as I understand it, is a measure of the phase noise in the
time received from the server. Think of sending packets over the
internet at EXACT 1 second intervals. Do you think that those packets
will arrive at their destination at the same EXACT 1 second intervals
at which they were sent? (If you do, I want some of whatever you're
smoking) :-)
Ive never been that stoned ;-) hence the previous msg comment
"show a large jump in the jitter from the distant source.
This probably doesnt mean anything, since its subject to the vagaries of
the network
across unknowable routes"
I would however expect much better timing jitter from a
null-ethernet-cable 'network'
without any other nodes, switches, just some traffic between the 1 boxes.
thanks again
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
