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@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....@lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon....@lists.ntp.org] On
> Behalf Of unruh
> Sent: Thursday, November 15, 2012 1:43 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] NTP.ORG MEINBERG KEEP TIME ACCURATE to
> 10MS
>
> On 2012-11-15, Richard B. Gilbert <rgilber...@comcast.net> wrote:
> > On 11/14/2012 12:02 AM, E-Mail Sent to this address will be added to
> > the BlackLists wrote:
> >> gbusenb...@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@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
