Find the answer to your Linux question:
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 22
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined! charlie_arya's Avatar
    Join Date
    Sep 2009
    Posts
    39

    Unhappy kernel clock drifts


    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.
    Last edited by devils casper; 08-04-2010 at 03:18 PM.

  2. #2
    RDU
    RDU is offline
    Just Joined!
    Join Date
    Aug 2010
    Posts
    89
    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.

  3. #3
    Just Joined! charlie_arya's Avatar
    Join Date
    Sep 2009
    Posts
    39
    Quote Originally Posted by RDU View Post
    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?

    Last edited by devils casper; 08-04-2010 at 03:18 PM.

  4. $spacer_open
    $spacer_close
  5. #4
    RDU
    RDU is offline
    Just Joined!
    Join Date
    Aug 2010
    Posts
    89
    Quote Originally Posted by charlie_arya View Post

    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.

  6. #5
    Just Joined! charlie_arya's Avatar
    Join Date
    Sep 2009
    Posts
    39

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








    Moderator's Note : Use default Font color only.
    Last edited by devils casper; 08-04-2010 at 03:19 PM.

  7. #6
    Just Joined!
    Join Date
    Jun 2009
    Posts
    16
    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?

  8. #7
    RDU
    RDU is offline
    Just Joined!
    Join Date
    Aug 2010
    Posts
    89
    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.

  9. #8
    Linux Engineer Segfault's Avatar
    Join Date
    Jun 2008
    Location
    Acadiana
    Posts
    877
    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?

  10. #9
    RDU
    RDU is offline
    Just Joined!
    Join Date
    Aug 2010
    Posts
    89
    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

  11. #10
    Just Joined!
    Join Date
    Jun 2009
    Posts
    16
    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.

Page 1 of 3 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •