Here is what ntpq -p shows at my place:
remote refid st t when poll reach delay offset
jitter
==============================================================================
*LOCAL(0) 73.78.73.84 5 l 63 64 377 0.000 0.000
0.001
time-b.nist.gov .RSTR. 16 u - 64 0 0.000 0.000
4000.00
time-b.nist.gov .RSTR. 16 u - 64 0 0.000 0.000
4000.00
time-A.timefreq .RSTR. 16 u - 64 0 0.000 0.000
4000.00
time.nist.gov .RSTR. 16 u - 64 0 0.000 0.000
4000.00
And this is after a whole day of operation...
Sure doesn't look like yours..
On Tue, 9 May 2006, Richard B. Gilbert wrote:
Ted Gervais wrote:
Well I finally am moving away from netdate and have ntpd installed and
running.
I brought it up using ntpd -g, and hope that is ok.
Also I have no idea that it is doing anthing? How do I know that it is
running.
The drift file has only one entry in it, and that is all zeros..
Is there some way that I can watch what is happening like the way I watch
log files using 'tail -f messages' ??
I have all the logfile stuff turned on so I can read any and all stuff that
is happening and yet while that says a few things I at this point don't
know that it is doing anything with the system time.
I am running linux (slackware 10.2)..
ntpq -p
It will show you a "billboard" listing, for each server:
1. whether it is selected (*=selected, +=candidate, -not a candidate, X
insane.
2. the name or IP address
3. the reference ID
4. the stratum
5. the type
6. when it was last polled
7. the poll interval
8. reachability (eight bit shift register in octal. A 1 is shifted in from
the right for each response from the server and a 0 for each failure to
respond; 0 is bad 377 is good.
9. The round trip delay to and from that server, in milliseconds.
10. The offset of your clock from that server, in milliseconds
11. The jitter, a measure of the random noise in the time received; low
numbers are good.
This display can look quite disappointing when you cold start ntpd. Ntpd may
need several hours to get your clock into really good synchroniation.
Here's a sample:
sunblok_$ ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*GPS_ONCORE(0) .GPS. 0 l 4 16 377 0.000 0.003 0.001
sunburn .WWV. 1 u 165 1024 377 0.450 42.953
1.821
+Internet-A .PSC. 1 u 42 64 377 17.061 1.635 2.089
-Internet-B .CDMA. 1 u 41 64 377 19.267 4.958 1.368
+Internet-C 18.145.0.30 2 u 12 64 377 16.014 2.134 3.440
+Internet-D 128.59.39.48 2 u 1 64 377 12.711 1.992 2.621
LOCAL(0) LOCAL(0) 10 l 35 64 377 0.000 0.000
0.001
This server uses a Motorola Oncore GPS Timing receiver as a reference clock.
It is selected as the primary synchroniztion source. Sunburn is a server on
my LAN using a WWV receiver as reference clock; it's the middle of the day
here and both signal reception and performance are extremely poor.
Internet-A, Internet-C and Internet-D are part of the "selection" set and act
as an "advisory committee". Internet-B with the longest round trip delay and
a relatively high value of jitter is not being used for anything at this
time.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
---
Ted Gervais
Coldbrook, Nova Scotia
Canada. (ve1drg)
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
