[ntp:questions] ntpq -p command query
elliott.ch at verizon.net
Wed Jul 31 13:01:55 UTC 2013
If he is using broadcast mode, what earthly difference does it make how
broadcasts? After 10:02:25:57 of uptime, on my time server NTPD has only
00:04:25 of CPU time. A broadcast takes NTPD literally less than a
and less than a millisecond to reach the clients.
It broadcasts the time to my home network every 16 seconds. It is also
to 9 nearby stratum 2 time servers with a minpoll of 4 and a maxpoll of 5 (=
seconds). Unless this list is it, no one has ever criticized me for
time server too frequently. It is completely unrealistic to query a time
every 1024 seconds (poll = 10) and expect accurate time thru a WAN whose
varies between about 40 ms and about 200 ms continually and unpredictably.
the normal delay is closer to 40 ms, one reading thru a delay of 180 ms can
the time off for hours, given that offset is significantly and negatively
with delay. For example, one of my favorite time servers is
(or clock01). This guy often uses ntp.coi.pw.edu.pl as a time server, which
at a technical university in Warsaw, Poland. When he does connect to that
his proffered time is about 17 ms less than the consensus of the other 8
servers. The same is nearly true when he uses a Microsoft time server
Redmond, WA. Until and unless Internet congestion abates, and until and
NTPD figures out why delay and offset are highly negatively correlated, a
interval of 32 to 64 seconds is the only way to maintain accurate time, in
Do correct me if I am wrong.
> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of unruh
> Sent: Tuesday, July 30, 2013 3:31 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] ntpq -p command query
> On 2013-07-30, Biswajit Panigrahi <BP00106533 at TechMahindra.com> wrote:
> > Hi,
> > I have configured the ntp server and ntp client on two machine.
> > Both are communicating properly. I would like to test when the
> > connectivity between those two goes down, after how much time the
> > "reach" option in ntpq -p command becomes zero.
> > For that I stopped the ntp server and I executed the ntpq -p in
> > client's console,
> > The reach option will still keep on increase to 377 then gradually
> > decreases to zero. The time duration to come to zero is almost 20
> > minute.
> > Can we reduce the time gap ?
> Why? Why do you care how rapidly the reach option goes to 0?
> ntpd only queries the server occasionally (default is 2^6 (about 1min
> startup and 2^10 (about 20 min) sec after things have stabilized.) Each
> time one of those attempts fails, one bit is lost from the reach, so it
> will go to zero after about 3 hrs. That is the way that ntpd works.
> Now you can if you wish have the client query more often. If you own
> server that is fine. If you do not own the server, that is considered
> very bad manners, and the server may refuse to serve you anymore.
> A shorter poll interval means that the offset is smaller but the rate
> correction is more inaccurate, meaning that if your system goes down
> clock will become inaccurate more rapidly. Since on a local net,
> the times within a few 10s of microseconds is very doable, it is not
> clear what youwant.
> > Please find the ntp.conf in client:
> > server 10.16.48.19 key 1
> > restrict 10.16.48.19 mask 255.255.255.255 nomodify notrap noquery
> > restrict 127.0.0.1
> > broadcastclient novolley
> > broadcastdelay 0
> > keys /var/ntp/keys
> > trustedkey 1
> > logfile /var/log/ntp/ntpd.log
> > driftfile /var/log/ntp/ntp.drift
> > statsdir /var/log/ntp/
> > statistics loopstats peerstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > Any suggestion will really appreciated.
> Stop worrying.
> > Regards,
> > Biswajit
> > Disclaimer: This message and the information contained herein is
> proprietary and confidential and subject to the
> > Tech Mahindra policy statement, you may review the policy at <a
> > externally and <a
> ahindra.com/tim/disclaimer.html</a> internally within Tech Mahindra.
> questions mailing list
> questions at lists.ntp.org
More information about the questions