On Thu, Dec 01, 2011 at 12:24:44AM +, Pete Ashdown wrote:
> Miroslav Lichvar 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).
That would sugg
On 2011-12-01, Pete Ashdown wrote:
> unruh 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 tim
On 2011-12-01, Pete Ashdown wrote:
> Miroslav Lichvar 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 have that 1 second offset from n
unruh 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.
Here is anothe
unruh 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 saw that all
Miroslav Lichvar 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
questions@lists.nt
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 three
On Wed, Nov 30, 2011 at 11:28:22PM +, unruh wrote:
> On 2011-11-30, Miroslav Lichvar 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 if it is re
On 2011-11-30, Miroslav Lichvar 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 if it is really
>> misbehaving that badly. Also, if it is out by 16 sec, w
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 if it is really
> misbehaving that badly. Also, if it is out by 16 sec, why in the world
> has ntp not stepped the tim
On 2011-11-30, Harlan Stenn wrote:
> Pete wrote:
>> "David J Taylor" 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 t
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 o
David Woolley 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 development kernels.
I think
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.
___
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 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 wrote:
> "David J Taylor" 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,
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
> cer
unruh 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
>approximati
On 2011-11-30, Pete Ashdown wrote:
> David Woolley 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?
>
=?utf-8?Q?Miguel_Gon=C3=A7alves?= writes:
>On 30/11/2011, at 15:41, Pete Ashdown wrote:
>> David Woolley 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
>>
On 2011-11-30, Pete Ashdown wrote:
> David Woolley 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?
>
On 30/11/2011, at 15:41, Pete Ashdown wrote:
> David Woolley 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 con
David Woolley 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 can, and someti
"David J Taylor" 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 using a drift file, an
On 11/29/2011 9:21 PM, unruh wrote:
On 2011-11-29, Richard B. Gilbert 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
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 "stea
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 th
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
On 2011-11-29, Richard B. Gilbert 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 when pol
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
===
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
=
32 matches
Mail list logo
