[EMAIL PROTECTED] 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. > > [EMAIL PROTECTED] 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
