[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

unruh unruh at invalid.ca
Thu Mar 15 21:06:06 UTC 2012

On 2012-03-15, Ron Frazier (NTP) <timekeepingntplist at c3energy.com> wrote:
>> On 2012-03-15, Ron Frazier (NTP)<timekeepingntplist at c3energy.com>  wrote:
>>> On 3/15/2012 11:42 AM, unruh wrote:
>>>> On 2012-03-14, Ron Frazier (NTP)<timekeepingntplist at c3energy.com>   wrote:
>>>>> On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:
>>>>>> On 3/14/2012 4:00 PM, David J Taylor wrote:
>>>>>>>> Hi David T,
>>>>>>>> NOW .... you understand.
>>> <snip>
>>>>> PS to my prior message.
>>>>> I don't think the problem so much is the delay to the internet servers,
>>>>> or even to get out of my house.  NTPD is supposed to take care of that
>>>>> as long as it's pretty much symmetrical.  I think the problem is that
>>>>> the Windows clock is like a wild tiger that doesn't want to be tamed and
>>>>> which is running every which way.  For whatever reason, cpu load, heat,
>>>>> cosmic vibrations, whatever, the intrinsic frequency of the windows
>>>>> clock is always changing.  In order to avoid beating up on the internet
>>>>> servers too much, I have to poll them at least every 4 minutes apart.
>>>>> If you let it, NTPD will extend that out to 16 minutes or more.  So,
>>>> Actually, the effective NTPD poll interval is abotu 8 times the stated
>>>> interval. The clock filter throws away about 7 out of 8 poll results in
>>>> an attempt to get rid of assmetric polls. Ie, it assumes that the
>>>> shortest round trip interval out of the past 8 is the best estimate of
>>>> the symmetric roundtrip and throws away the rest. Thus if you have
>>>> polling every 4 min  (poll interval 8) the effective interval is about
>>>> every half hour.
>>>> That is fine if the clock is an even half way reasonable clock (Ie rate does
>>>> not change by more than say 2PPM over that time)
>>> You're saying the effective polling interval is 8x what minpoll is.
>>>    However, if the access policy for a NIST server is no more than 20
>>> times per hour or every 3 minutes, and I set minpoll to 6 or
>>> approximately every minute, even if the clock algorithm throws away 7 of
>>> 8 samples; am I not still sampling?  Am I not still "hitting" the NIST
>>> server every minute and are they not going to ban me from accessing it
>>> if that continues?
>> Yes. The poll interval is whatever you ( or ntp sets it to). Ie, it goes
>> to the externam machine to get data that often. However, ntpd only uses
>> approximately 20% of the values it gets from that remote machine. Thus
>> as far as the ntp algorithm on your machine is concerned its effective
>> poll interval is much longer.
>> But why in the world are you going to the NIST servers for your time?
>> Use the pool. A stratum 2 or 3 server can certainly give you the ms
>> accuracy you apparently want. And if you are using gps, the only purpose
>> of the remote servers is a) fallback, and b) getting the second right.
>> None of those require NIST.
>> You can cut your polling of NIST to infinity without affecting your
>> time.
> Allow me to explain.  A long time ago in a galaxy far far away, I wanted 
> to synchronize the clocks of my Windows machines.  This was before I 
> knew anything about Linux or NTP.  However, being a US citizen, I knew 
> our government provided the National Institute of Standards and 
> Technology (NIST) agency, and that they had a Time and Frequency 
> division, just to help handle such things for US citizens and the world. 
>   So, I went here to the Time and Frequency division (the link address 
> may have changed over time):
> http://www.nist.gov/pml/div688/
> And then here to the Internet Time Service:
> http://www.nist.gov/pml/div688/grp40/its.cfm
> And I downloaed their little Windows time program here:
> http://www.nist.gov/pml/div688/grp40/upload/nistime-32bit.exe
> This thing is designed to poll the NIST servers (and only the NIST 
> servers) up to every 4 hours and set your clock.  That's all it does, 
> and I don't think it tries to tinker with the clock frequency.  I ran 
> that for many years, and still, sometimes, would get a couple of seconds 
> drift between polling intervals.  There is nothing on the website to 
> discourage average Joe users from using the system.
> A couple of years ago, I learned about and started using Ubuntu.  For 
> timekeeping there, I used NTP.  At the time, there was a graphical 
> interface to it and I picked about 8 random servers by ticking the check 
> boxes and let it run.
> Back around Christmas 2011, I got some atomic wall clocks and an atomic 
> watch and got fascinated with the idea of getting more accuracy for the 
> PC's.  That led me to doing reserach and that led me to install the 
> Meinberg port of NTP.  Of course, then, I had to figure out how to add 
> servers and set up ntp.conf.
> In answer to your question, I'm using NIST because:
>       a) My government provides it and, through their website, 
> encourages the public to use it.
>       b) I was familiar with it.
>       c) I thought it would be more accurate.
> Having said that, I could discontinue using it if the need arises.

And since your early forays into timekeeping, you have learned that NIST
does not anyone querying them more often than about 2-3 times an hour,
that they are a stratum 1 source  which are a relatively precious
commodity, and want to be a responsible ntp net citizen.   I am not
blaming you for having used them, but since you have learned more, you
have discovered more. It may be more accurate, but that accuracy is also
useless to you, since your system does not need and cannot use
microsecond accuracy. 

> So, I put 4 NIST servers, 4 stratum 2 servers, 4 US pool servers, and 
> just for good measure, the Ubuntu time server in my ntp.conf.  Since all 

And exactly why did you think using 13 servers would be a good thing?
For what you are doing it is way overkill. 

> queries exiting my house show the same IP address, each computer prefers 
> to use a different NIST server so one server doesn't see as many 
> apparent requests.
> Not long after getting NTP working on Windows, I decided to get into the 
> whole GPS thing.  Hence, all the discussions I've had on this list.  My 
> current goal is to set up my own GPS time server, that doesn't wander, 
> and use internet servers as a backup, as you said.

That is of course great. The more people learning about time, the

>>>>> when the clock source is polled, say the PC clock is too fast, so NTPD
>>>>> slows it down.  Then, when you poll the clock source again, say the PC
>>>>> clock is too slow, so NTPD speeds it up.  Because of the varying
>>>>> intrinsic frequency of the clock, you can never find a clock speed that
>>>>> just works, because then the system goes and changes, by changes in the
>>>>> oscillator, how much time passes at those particular settings.  It's a
>>>>> battle you cannot win.  By polling my GPS every 8 seconds, I can keep
>>>>> the clock under control based on it's current needs which are varying
>>>>> second by second.  Of course, when discussing internet servers, 30 ms of
>>>> What are you talking about. There is no evicence either in your data or
>>>> in any reports by anyone of 30ms variation is network offsets.
>>>> Even on ADSL, it is in the microsecond range, not millisecond.
>>> I'm not sure exactly what you're asking.  If you're referring to my
>>> comment about internet peer jitter, I occasionally see jitter numbers
>>> for internet peers on the Meinberg Time server monitor screen in the 20
>>> - 30 ms range and more frequently see numbers in the 10 - 20 ms range
>>> for jitter.  Here is a recent screen shot:
>>> http://dl.dropbox.com/u/9879631/internet%20jitter%20example.jpg
>>> Note that there are three peers with jitter in the 10 - 20 ms range.
>> Then there is something extremely wrong with those peers. Stop using
>> them.
>>> If you were asking about the offsets my computers experience using the
>>> internet as a time source, my TAZ computer polls the internet
>>> exclusively and it's offsets routinely fluctuate + / - 50 ms.
>>> http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg
>>> http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
>>> http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
>>> http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ
>> AGain, that is not usual and indicates something is wrong. It is not use
>> use of the internet. Something else is very wrong. Using an internet
>> peer 50ms away I get jitter of less than 100us. (not ms), and I think
>> that experience is far more typical. If it is your network that is the
>> problem then it is especially silly to use a source like NIST, since its
>> is being totally wasted.
> I respectfully suggest, that, if you're not in the US, then your 
> experience is probably not typical of what goes on in the US.  Even in 
> the country, there is very much variation in performance of the 
> internet.  I cannot say whether my network, my ISP, or my country's 
> internet, or all three cause the poor NTP performance.  It is what it 
> is.  It's what I have to deal with.  Keep in mind that, hypothetically, 
> since I'm in the Southeast, if I were to poll a server in the Northwest, 
> that would be a 7000 mile round trip for the data, probably crossing 15 
> or more routers.  I've given up trying to get great performance out of 
> internet NTP servers.  Even with my crummy (for timekeeping) little USB 
> only GPS, I'm getting 10 times better performance from it when it works 
> right than I do from the internet.  I'm just going to set up my own time 
> server and not worry about what the internet servers are doing.

Fine. My comments were not about myself (I certainly get far better
accuracy out of the internet than 30ms) but from having read other
posts here. From what I have seen most people get a lot better than 30ms
out of internet servers. 
Before hitting on 13 different servers, it would be better tofigure out
what the problem is that is giving you such lousy results. While I agree
that reforming the whole internet of the Southwest USA is probably
beyond your abilities, it may be that the problem is much closer to
> Sincerely,
> Ron

More information about the questions mailing list