[ntp:questions] NTP.ORG MEINBERG KEEP TIME ACCURATE to 10MS

unruh unruh at invalid.ca
Thu Nov 15 06:43:08 UTC 2012


On 2012-11-15, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 11/14/2012 12:02 AM, E-Mail Sent to this address will be added to the 
> BlackLists wrote:
>> gbusenberg at yahoo.com wrote:
>>> I am now left with two lines in ntp.conf
>>> driftfile "C:\Program Files\NTP\etc\ntp.drift"
>>> server 10.1.126.204 iburst minpoll 5
>>
>> There have been plenty of improvemnets since 4.2.6p5 circa 2011Dec24
>> <http://www.davehart.net/ntp/win/x86/ntp-4.2.7p310-win-x86-debug-bin.zip>
>> <http://www.davehart.net/ntp/win/x86/ntp-4.2.7p310-win-x86-debug-sym.zip>
>>
>> # ALL (Clients and/or Servers)
>> #  Start the Service with C:\Program Files\NTP\bin\ntpd.exe -U 3 -M -g -c "C:\Program Files\NTP\etc\ntp.conf"
>> #   the -g will prevent a panic stop if the time needs to be steped when started
>>
>> # ntp.conf
>> driftfile "C:\Program Files\NTP\etc\ntp.drift"
>> statsdir "C:\Program Files\NTP\etc\"
>> enable monitor
>> enable stats
>> statistics loopstats peerstats
>> keys "C:\Program Files\NTP\etc\ntp.keys" # e.g. contains: 123 M YOUR_MD5_KEY
>> trustedkey 123
>> tos cohort 1 orphan 11
>> restrict default limited kod nomodify notrap
>> restrict 127.0.0.1
>> restrict source nomodify
>> broadcastclient
>> manycastserver  224.0.1.1
>> multicastclient 224.0.1.1 key 123 preempt
>> manycastclient  224.0.1.1 key 123 preempt
>> pool pool.ntp.org preempt                # Won't hurt anything if the internet can't be reached
>> server 10.1.126.204 iburst key 123
>>
>> # If you address the server by name append preempt
>> # Let NTP worry about the minpoll and maxpoll for LAN devices
>>
>> # They should all try to sync to 10.1.126.204
>> #  If they can't reach 10.1.126.204 they should all try to stick together
>>
>> # NTP expects to be run continuously; After a Boot/Reboot/Restart/...
>> #  give the systems 30 minutes to stabilize polls and temperature
>> #   before expecting too much from the ntpq stats
>>
> 30 minutes is more than a little optimistic!  NTPD needs something like 
> ten hours to stabilize with the best time you are going to get.  Thirty 
> minutes after startup is about when NTPD gets days, hours, and minutes
> right.  The next nine and a half hours will be devoted to improve the
> accuracy.

Well, no. He wants 10ms accuracy, not 10usec. ntpd does about a factor
of 2 improvement per hour ( a bit less). Thus that 10 hours is mostly
spent in driving the time through that last factor of a thousand in
improvement. 10 ms you should get within a few hours. 

However, since ntpd steps if the time is out by more than 128ms once it
is sure it is, his errors suggest that the offset time is jumping around
by hundreds of ms, so ntpd never decides that things are reliably out by
that 128ms. It would really help to see that peerstats plot of offset vs
time and delay vs time. And also from that server, because it may be
where theproblem lies. 


>
> This should suggest to you that NTDP should be run 24 hours a day, seven 
> days a week. . . . .

10ms should be doable within an hour or so. 

>
> It's not always possible, but TRY!
>
>



More information about the questions mailing list