[ntp:questions] ntpq -p command query

unruh unruh at invalid.ca
Wed Jul 31 14:31:36 UTC 2013


On 2013-07-31, Charles Elliott <elliott.ch at verizon.net> wrote:
> If he is using broadcast mode, what earthly difference does it make how
> often he 
> broadcasts?  After 10:02:25:57 of uptime, on my time server NTPD has only
> used 
> 00:04:25 of CPU time.  A broadcast takes NTPD literally less than a
> microsecond, 
> and less than a millisecond to reach the clients.  
> It broadcasts the time to my home network every 16 seconds. It is also
> connected 
> to 9 nearby stratum 2 time servers with a minpoll of 4 and a maxpoll of 5 (=
> 32 
> seconds).  Unless this list is it, no one has ever criticized me for
> querying a 
> time server too frequently.  It is completely unrealistic to query a time

Well, you obviously have not read this list very long then.

There have been a number of ntp servers that have been brought down by
1000000 other machine continually polling them because some manufacturer
thought just like you do "what does it matter if I behave like an ass?"
What does it matter if I spit in the street. There are 1000 sqare miles
in the city and my spit only takes up 1 square cm at most. etc.



> server
> every 1024 seconds (poll = 10) and expect accurate time thru a WAN whose
> delay 
> varies between about 40 ms and about 200 ms continually and unpredictably.

Go out and buy yourself a GPS receiver ($40 from
www.sureelectronics.com) and set it up. That way you will get accurate
time (microsecond accuracy). 


> Where
> the normal delay is closer to 40 ms, one reading thru a delay of 180 ms can
> throw
> the time off for hours, given that offset is significantly and negatively

No it cannot. ntp uses the poll of the last 8 which has the lowest
delay. One poll of 180ms will not "through it off".


> correlated 
> with delay.  For example, one of my favorite time servers is
> clock02.sctn01.burst.net

This is your favourite server even though his time is out. Sheesh. You
need examine your judgement.


> (or clock01).  This guy often uses ntp.coi.pw.edu.pl as a time server, which
> is
> at a technical university in Warsaw, Poland. When he does connect to that
> server,
> his proffered time is about 17 ms less than the consensus of the other 8
> stratum 2
> servers.  The same is nearly true when he uses a Microsoft time server
> located in
> Redmond, WA.  Until and unless Internet congestion abates, and until and
> unless
> NTPD figures out why delay and offset are highly negatively correlated, a
> poll
> interval of 32 to 64 seconds is the only way to maintain accurate time, in
> my
> humble opinion.

And your humble opinion is, I am afraid, not worth much. 


>
> Do correct me if I am wrong.

I did. It is the usual problem of the commons "My antisocial actions
will not matter much so why not do them". Unfortunately, a number of
people think the same way ( especially some manufacturers), and manage
to destroy the commons for everyone. 

IF you are using someone else's stuff, get permission first if you are
going to use more of it than he expects. All the public servers expect
you to use them once a minute or so when starting up, and once an hour
or so once settled down. If you are going to use more of their resources
than that, ask first. 


>
> Charles Elliott
>
>> -----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
>> on
>> 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
>> the
>> 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
>> the
>> clock will become inaccurate more rapidly. Since on a local net,
>> keeping
>> 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
>> href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahin
>> dra.com/Disclaimer.html</a>
>> > externally and <a
>> href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.techm
>> ahindra.com/tim/disclaimer.html</a> internally within Tech Mahindra.
>> >======================================================================
>> ======================================================
>> 
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list