[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