"David Woolley" wrote in message
news:hd8j1u$ou...@news.eternal-september.org...
> David J Taylor wrote:
>
>> http://www.satsignal.eu/mrtg/performance_narvik.php
>
> How much of that offset do you attribute to actual clock error?
>
> If most of it, that graph makes a strong case for a low maxpo
David J Taylor wrote:
> http://www.satsignal.eu/mrtg/performance_narvik.php
How much of that offset do you attribute to actual clock error?
If most of it, that graph makes a strong case for a low maxpoll, or a
different algorithm.
___
questions mail
David Woolley writes:
>David J Taylor wrote:
>> http://www.satsignal.eu/mrtg/performance_narvik.php
>How much of that offset do you attribute to actual clock error?
>If most of it, that graph makes a strong case for a low maxpoll, or a
>different algorithm.
a) This is windows.
b) Except for
"Unruh" wrote in message
news:6gujm.51215$db2.19...@edtnps83...
[]
> a) This is windows.
.. and so more of a challenge to get good timekeeping.
> b) Except for the abberation at 12, the offset seems to track the disk
> temp.
> However, it is not the offset which is important but the rate. It
On Nov 9, 9:21 am, "David J Taylor" wrote:
>
> Here's the offset:
> http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png
>
> and here's the rate:
> http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_frequency-tod.png
>
> where values for the last two and half days have been overla
Evandro Menezes writes:
>On Nov 9, 9:21=A0am, "David J Taylor" bit.nor-this.co.uk.invalid> wrote:
>>
>> Here's the offset:
>> =A0http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png
>>
>> and here's the rate:
>> =A0http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_frequency-tod.pn
Unruh wrote:
> Well, you do have that choice, only in different names. chrony uses an
> entirely
> different algorithm (directly estimating the rate and the offset from a
> sequence
Looking at the graphs, one needs the first derivative of the rate, as well.
> of measurments). Of course you do
My problem is a client with several systems using a single GPS-based
NTP server.
A couple of these systems have had occasions where the clock has
suddenly stepped around 10,000 seconds backwards:
Oct 15 13:22:03 xxx xntpd[403]: [ID 261039 daemon.error] time error
-10369.999603 is way too large (se
On 2009-11-09, PhilipPeake wrote:
> A couple of these systems have had occasions where the clock has
> suddenly stepped around 10,000 seconds backwards:
>
> Oct 15 13:22:03 xxx xntpd[403]: [ID 261039 daemon.error] time error
> -10369.999603 is way too large (set clock manually)
I'd look for some
Evandro Menezes wrote:
> I'd sure like to decide what's good for me, not Mills.
What is stopping _you_ from modifying NTP to meet your needs?
--
E-Mail Sent to this address
will be added to the BlackLists.
___
questions mailing list
questions@list
10 matches
Mail list logo
