kernel clock drifts

[charlie_arya]

Hi,

I am running 2.6.27 kernel on my arm AT91SAM9G20. I am not using ntpd. I sync my kernel time with the reference time and then leave the system for 24 hours. I see that the kernel clock drifts by 8 seconds. Can anyone help me in figuring out the reason behind this. And how to fix this in kernel?


Moderator's Note : Use default Font color only.

[RDU]

Propably your XTAL clock is not exactly correct. Try to mesure it. 8 second per day is about 100ppm wich is normal for simple xtal clock. To get more precise (1 to 10ppm), should use a OCXO (temperature controled).

You have few options :

1.Use a beter clock or adjust the current one (xtal can be adjusted a little bit with a capacitor).

2. keep like this, mesure the drift and compensate (e.g. change the time bye 1 second every 3 hour). But this is step and not smooth transition. Depend on what you're running but this can cause problem.

3.run ntpdate every let says hour

4.keep ntpd running

3 and 4 need network connectivity. You can also use GPS data to synchronise your clock.

[charlie_arya]

Propably your XTAL clock is not exactly correct. Try to mesure it. 8 second per day is about 100ppm wich is normal for simple xtal clock. To get more precise (1 to 10ppm), should use a OCXO (temperature controled).

You have few options :

1.Use a beter clock or adjust the current one (xtal can be adjusted a little bit with a capacitor).

2. keep like this, mesure the drift and compensate (e.g. change the time bye 1 second every 3 hour). But this is step and not smooth transition. Depend on what you're running but this can cause problem.

3.run ntpdate every let says hour

4.keep ntpd running

3 and 4 need network connectivity. You can also use GPS data to synchronise your clock.

Hey, Thanks for reply. It is not possible to do hardware modifications. And ntpd options rules out as not all the boards are connected to network. I thought of option 2 but its simply a bad workaround.
1. If there is any modifications we can do in kernel?
2. And from s/w point of view what can be the reason for the drift?
3. Is it fully due to H/W?
4. How kernel take care of drifts?

[RDU]

Hey, Thanks for reply. It is not possible to do hardware modifications. And ntpd options rules out as not all the boards are connected to network. I thought of option 2 but its simply a bad workaround.
1. If there is any modifications we can do in kernel?
2. And from s/w point of view what can be the reason for the drift?
3. Is it fully due to H/W?
4. How kernel take care of drifts?

Sure this workaround is not 'good'.

1.Not sure but probably you could correct the divider (from clock tick) and rebuild a modified kernel. But all your board should have the same drift.
2.Could be an incorrect divider or interrupt lost (clock run then too slowly)
3.It seem you have several boards. Have you try if all of them have the same drift ? Did you have a good frequency meter to check the clock exactly ?
4.Don't know, sorry. I leave other people answer.

[charlie_arya]

Ya, we have several boards and all thee boards have this issue.








Moderator's Note : Use default Font color only.

[lewmur]

First of all, the kernel doesn't keep time so you can't "adjust" it. It merely "reads" the time from your MB's clock. What you can do is measure the drift over a period of, say a week, and if the drift is consistent for a given computer, you could add a routine to the task scheduler to "adjust" the time by reseting the clock's time periodically.

BTW, just how critical is the issue? Is it just a question of the users having to "reset their clocks" once a month? Or are you using the computers for a "process control" that has to be that precise or a national disaster will occur?

[RDU]

I don't agree. Kernel keep time itself. It read the MB clock at startup and save it at shutdown. In the mean time, it compute time based on interrupt generated X time per second.
For instance, clock IS working on motherboard WITHOUT clock chips like embedded (ALIX for instance). Of course it start at 1-1-1970 00:00 at reboot and you've to set it or use ntp.

[Segfault]

Never dug deep into NTP (because it just works), but methinks it learns the clock drift and can compensate for it even when not connected to the net?

[RDU]

Correct, it keep a 'drift' file. But it need to connect from time to time to internet to keep it accurate. Of course, you can maybe provide it with a crafted drift file, but never tried

[lewmur]

There is no such thing as a "drift file." Linux reads the BIOS clock for timing. NTP merely resets the BIOS clock to match whatever "standard" clock you have it set to read over the Internet, on an occasional basis.

To put it simply, RDU doesn't know what he/she is talking about.