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

Charles Elliott elliott.ch at verizon.net
Thu Nov 15 16:36:42 UTC 2012


	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.


	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