[ntp:questions] LAN synch question
David Woolley
david at ex.djwhome.demon.co.uk.invalid
Thu Sep 11 22:21:07 UTC 2008
rochertov at gmail.com wrote:
> I have used ntpdc and ntpq on the same machine that tries to synch
> with an
> ntp server (192.168.0.4). The ntp server uses its own system clock
> which is
> not disciplined (need to figure out how to do that). I am curious as
> to why
> the reported offsets are different.
You have run ntpdc against the client and ntpq against the server,
probably at slightly different times, as well. ntpdc reports in seconds
and ntpq in milliseconds.
>
> ntpdc> peers
> remote local st poll reach delay offset disp
> ==========================================================
> =LOCAL(0) 127.0.0.1 5 64 377 0.00000 0.000000
> 0.03059
> *192.168.0.4 192.168.0.20 6 16 377 0.00011 0.007474
> 0.02922
This is brinkmanship. You only get away with it because there is a
built in bias against the local clock, even though its stratum favours
it. You should never use it on pure clients and you should make sure it
is outvoted by real servers.
>
> [root at term1 etc]# ntpq -p ntp
> remote refid st t when poll reach delay
> offset jitter
> ==========================================================
> 192.168.0.255 .BCST. 16 u - 64 0 0.000
> 0.000 0.001
> *LOCAL(0) .LOCL. 5 l 51 64 377 0.000
> 0.000 0.001
Local clock at stratum 5 plus broadcast client is not sensible. A more
detailed explanation in another thread.
>
>
> Also, David, did you mean 100 nano-seconds or 100 micro-seconds? I
> would be
Sorry. I got confused. 100ns is getting near the limits for an ideal
environment. 100 microseconds is often achieved on a lightly loaded
LAN, with a local reference clock, but may be violated during
temperature excursions.
More information about the questions
mailing list