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

unruh unruh at invalid.ca
Thu Mar 15 17:56:02 UTC 2012


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.




>
>>> 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. 


>
> Sincerely,
>
> Ron
>
>>> jitter doesn't help any.
>
><snip>
>
>



More information about the questions mailing list