Prev: ntpd question
Next: slack 13 OpenOffice
From: root on 3 Nov 2009 05:54
Petri Kaukasoina <kaukasoina802n54jc045(a)sci.fi> wrote:
> Petri Kaukasoina <kaukasoina802n54jc045(a)sci.fi> wrote:
>>root <NoEMail(a)home.org> wrote:
>>>After over two hours of operation
>>>I had drifted by 84 seconds, which is just the
>>>drift I had always been getting.
>>
>>So, the rate of your clock is about 11700 ppm too fast or too slow.
>
> By the way, which clock source are you using?
>
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>
> For example, if you are not using "acpi_pm" but if it is available, you
> could try to use it (as root):
>
> echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

The first gives me jiffies. The second says I can use
jiffies or tsc.
From: Petri Kaukasoina on 3 Nov 2009 07:35
root <NoEMail(a)home.org> wrote:
>The adjtimex man page was a gift, thanks. I played around
>with various tick values. It turns out you need not run
>the system for any longer than 10 minutes with a given
>tick value to resolve the "correct" value to within +/- 1
>After trying your original value, I found I needed to
>correct 10117 to 10094. Finally I had to change that to
>10093:
>10094 after 10 min -.208 sec
>10093 after 10 min .022 sec
>

Now that you have tuned the tick value so accurately, the error in clock
rate will probable be less than 50 ppm (change of 1 in the tick value
changes the rate by about 100 ppm). You could tinker with it even more if
you didn't use ntpd: for example "ntptime -f -1.234" or "ntptime -f 1.234"
would change the frequency by -1.234 or +1.234 ppm. This is the same value
that ntpd is changing and which ntpd writes in /etc/ntp/drift. Of course,
ntpd can do it better than you because it can compensate against rate
changes caused by temperature changes (both ambient and cpu load related) by
syncing to reference ntp servers.
From: root on 3 Nov 2009 11:05
root <NoEMail(a)home.org> wrote:
>
> I have restarted ntpd, and will check after running
> 100 minutes.
>
> Thanks again.
>

According to my setting of tick, after 100 minutes the
clock would have been off by 2 sec. Instead it was spot
on. I continued the test, now after 440 minutes the
clock is still perfect. ntpd is working now.

Thanks to everyone.
From: root on 3 Nov 2009 11:10
Petri Kaukasoina <kaukasoina802n54jc045(a)sci.fi> wrote:
>
> Now that you have tuned the tick value so accurately, the error in clock
> rate will probable be less than 50 ppm (change of 1 in the tick value
> changes the rate by about 100 ppm). You could tinker with it even more if
> you didn't use ntpd: for example "ntptime -f -1.234" or "ntptime -f 1.234"
> would change the frequency by -1.234 or +1.234 ppm. This is the same value
> that ntpd is changing and which ntpd writes in /etc/ntp/drift. Of course,
> ntpd can do it better than you because it can compensate against rate
> changes caused by temperature changes (both ambient and cpu load related) by
> syncing to reference ntp servers.

After something like 450 minutes of operation the drift value
is 23.365. My clock is way more accurate than I need now.
Thanks for your help.

After this experience I offered to fix the clock on my
wife's machine. Her clock is accurate to a couple of
seconds/week so she doesn't need my help.
From: Henrik Carlqvist on 3 Nov 2009 17:19
root <NoEMail(a)home.org> wrote:
> I would have designed ntpd to set the time immediately after invocation
> (which it doesn't).

On my machines I call ntpdate just before starting ntpd. That gives me the
behavior that you want.

Nice to see that you were able to get ntpd working with tickadj.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root(a)localhost postmaster(a)localhost

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ntpd question
Next: slack 13 OpenOffice