On Thu, Dec 01, 2011 at 12:24:44AM +, Pete Ashdown wrote:
Miroslav Lichvar mlich...@redhat.com writes:
Would be interesting to know if this happens on every ntpd restart or
only shortly after the GPS unit was powered up.
Every restart (that doesn't have 127.127.0.1 in the config).
On 2011-12-01, Pete Ashdown pashd...@xmission.com wrote:
unruh un...@invalid.ca writes:
If he has peerstats log file, he can look at it and see what teh offset
is of the oncore and the other ntp sources to see if it is really
misbehaving that badly. Also, if it is out by 16 sec, why in the world
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there anything I can do to decrease the convergence time?
Little or nothing! NTPD can, and sometimes does, take ten hours to
reach
On 11/29/2011 9:21 PM, unruh wrote:
On 2011-11-29, Richard B. Gilbertrgilber...@comcast.net wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look pretty
good:
David J Taylor david-tay...@blueyonder.co.uk.invalid writes:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look
pretty
good:
[]
Is there anything I can do to decrease the convergence time?
Peter,
Are you
David Woolley david@ex.djwhome.demon.invalid writes:
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there anything I can do to decrease the convergence time?
Little or nothing! NTPD
On 30/11/2011, at 15:41, Pete Ashdown pashd...@xmission.com wrote:
David Woolley david@ex.djwhome.demon.invalid writes:
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there
On 2011-11-30, Pete Ashdown pashd...@xmission.com wrote:
David Woolley david@ex.djwhome.demon.invalid writes:
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there anything I can do to
=?utf-8?Q?Miguel_Gon=C3=A7alves?= m...@miguelgoncalves.com writes:
On 30/11/2011, at 15:41, Pete Ashdown pashd...@xmission.com wrote:
David Woolley david@ex.djwhome.demon.invalid writes:
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS.
On 2011-11-30, Pete Ashdown pashd...@xmission.com wrote:
David Woolley david@ex.djwhome.demon.invalid writes:
Richard B. Gilbert wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
+time-C.timefreq .ACTS. 1 u 19 64 377 37.887
-16011. 0.122
Is there anything I can do to
unruh un...@invalid.ca writes:
Uh, that is NOT the local hardware clock. That is local system clock.
Ie, the clock you are trying to discipline with ntpd.
Ie, you are setting the clock with itself, and so it will always have
zero offset-- super convergence, but unfortunately not to anything even
Richard wrote:
I think the effect of getting rid of the drift file depends on the
value stored in the file! If the value is reasonably close to
correct, I think it's helpful. If you are restarting because you have
been without power for the last three hours, the drift file is almost
Pete wrote:
David J Taylor david-tay...@blueyonder.co.uk.invalid writes:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look
pretty
good:
[]
Is there anything I can do to decrease the convergence time?
Pete wrote:
Thanks for the pointer David. I added the local hardware clock
(127.127.1.0) to the ntp.conf and that nailed it down. Now my
convergence is under a minute!
In general this is a bad idea. But if you have done the research and
know what you are doing, it may be OK.
H
Pete Ashdown wrote:
Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
That looks like an unstable kernel and a release candidate ntpd. I'm
not surprised that it has problems. I'm assuming that odd numbers still
indicate unstable development kernels.
Pete Ashdown wrote:
Thanks for the pointer David. I added the local hardware clock (127.127.1.0)
to the ntp.conf and that nailed it down. Now my convergence is under a
minute!
That's not logical and certainly not something that I would advise.
David Woolley david@ex.djwhome.demon.invalid writes:
Pete Ashdown wrote:
Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
That looks like an unstable kernel and a release candidate ntpd. I'm
not surprised that it has problems. I'm assuming that odd numbers still
indicate unstable
David wrote:
Ubuntu Linux 10.04, Kernel 3.1.0, ntp-4.2.6p5-RC1
That looks like an unstable kernel and a release candidate ntpd. I'm
not surprised that it has problems. I'm assuming that odd numbers still
indicate unstable development kernels.
4.2.6p5-RC1 is not the problem. The only
On 2011-11-30, Harlan Stenn st...@ntp.org wrote:
Pete wrote:
David J Taylor david-tay...@blueyonder.co.uk.invalid writes:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look
pretty
good:
[]
Is there
On Wed, Nov 30, 2011 at 11:28:22PM +, unruh wrote:
On 2011-11-30, Miroslav Lichvar mlich...@redhat.com wrote:
On Wed, Nov 30, 2011 at 10:24:45PM +, unruh wrote:
If he has peerstats log file, he can look at it and see what teh offset
is of the oncore and the other ntp sources to see
On 11/30/2011 4:28 PM, Harlan Stenn wrote:
Richard wrote:
I think the effect of getting rid of the drift file depends on the
value stored in the file! If the value is reasonably close to
correct, I think it's helpful. If you are restarting because you have
been without power for the last
Miroslav Lichvar mlich...@redhat.com writes:
Would be interesting to know if this happens on every ntpd restart or
only shortly after the GPS unit was powered up.
Every restart (that doesn't have 127.127.0.1 in the config).
___
questions mailing list
unruh un...@invalid.ca writes:
But how could he get a 16 second offset, after starting out with a .1 s
and 1 s offset. At 500PPM, 16 sec takes 32000 sec (10 hr) to accumulate
which is poll interval 15. Ie, I cannot see how ntpd could have
allowed that huge an offset to occur.
In the posts I
unruh un...@invalid.ca writes:
If he has peerstats log file, he can look at it and see what teh offset
is of the oncore and the other ntp sources to see if it is really
misbehaving that badly. Also, if it is out by 16 sec, why in the world
has ntp not stepped the time? The threshold is 128ms.
On 2011-12-01, Pete Ashdown pashd...@xmission.com wrote:
Miroslav Lichvar mlich...@redhat.com writes:
Would be interesting to know if this happens on every ntpd restart or
only shortly after the GPS unit was powered up.
Every restart (that doesn't have 127.127.0.1 in the config).
Does the GPS
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look pretty
good:
remote refid st t when poll reach delay offset jitter
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look pretty
good:
remote refid st t when poll reach delay offset jitter
On 2011-11-29, Richard B. Gilbert rgilber...@comcast.net wrote:
On 11/29/2011 1:42 PM, Pete Ashdown wrote:
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look pretty
good:
remote refid st t
Bill wrote:
Possibly chrony. Except that the price of faster convergence is vastly
improved accuracy and just as stable as NTPD.
But it only runs on Linux or bsd, not windows.
You have a very interesting view of the world. As best as I can tell,
you live in a world with really bad clocks
Running with an Oncore GPS a TAPR TAC. If I ntpdate -b a nearby
synchronized server before I start ntpd, the offsets initially look
pretty
good:
[]
Is there anything I can do to decrease the convergence time?
Peter,
Are you using a drift file, and allowing it to get a good value for the
30 matches
Mail list logo
