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

unruh unruh at invalid.ca
Thu Nov 15 17:47:38 UTC 2012


On 2012-11-15, Charles Elliott <elliott.ch at verizon.net> wrote:
> 	I don't understand where you guys are getting these long times for
> NTPD to settle out to an accurate
> reading.  I have one server connected to 9 stratum 2 servers over the
> Internet, and 4 clients receiving
> time broadcast from that server.  When I wrote before, the server did
> nothing but NTPD, DNS, and WINS, but
> now a different machine is server and does nothing but NTP, DNS, and WINS
> and processes Seti at Home workunits
> on its GPU. but that change appears to be making no difference to the time.

IF ntpd starts up with an accurate estimate of the rate and the offset
then it does not take so long. If you up the rate it does not take so
long. But with poll time of 64 sec ntpd gets roughly one data point
every 7 miniutes, and if the rate is wrong, the clock gaily wanders off
until finally the offset is so large that the rate starts to change and
the clock starts to get pulled back toward the right time and rate. The
exponential settling time is roughly an hour ( ie every hour the error
decreases by about 1/e=.4) 

>
>
> 	This morning when I had to reboot this machine upon which I write, a
> client, NTPD was showing an
> offset less than 1 ms in about a minute, and now, after 4:56:02 of
> operation, the offset is 0.007 ms with
> about 0.21N jitter.  The server was not reboot or restarted, just this
> client.  Where are you guys getting
> 10 hours to a day for NTPD to settle out?  Are you comparing NTPD to some
> other source of time?
>
> 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: Thursday, November 15, 2012 1:43 AM
>> To: questions at lists.ntp.org
>> Subject: Re: [ntp:questions] NTP.ORG MEINBERG KEEP TIME ACCURATE to
>> 10MS
>> 
>> 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!
>> >
>> >
>> 
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list