On Thu, 2003-10-09 at 00:48, Rik Tindall wrote: > >Mine works now, thanks for the suggestions. The on-board clock is not very > >good though, so I am upping the number of calls to ntpdate from 1 to 4 (at > >3, 9, 15 and 21:10 hours).
Your OS clock should be running independantly of the hardware clock, so the inaccuracy of the hw (time)clock will only bite you when you reboot after a period of being switched off. However, if your hw interrupt ticks are coming in unreliably, then your OS clock will drift on its own. If your clock deviations are larger than 0.5 seconds, ntpdate will step the time in one go, which isn't too healthy if you really care about your log file time data. On the other hand, if you force it to slew the clock instead, large deviations can take a *very* long time to be corrected. Generally, if you're wanting to set the clock more often than "once per boot", you're better off (in a sort of "Do The Right Thing" manner) running ntpd instead. This does more intelligent thinking about how your clock deviates from normality, and how to correct it. ntpd looks more complicated to set up, but it's basically the same as ntpdate - tell it the name of a better time reference server than yourself, and off it goes. The major downside is that while you are fiddling setting it up, ntpd hangs around idly for large periods of time - while you're poking in log files thinking that it's doing nothing. You're right, it *is* doing nothing, but it soon will be doing _something_ ... Oh, and ntpd often refuses to fix large deviations on its own ... so many good ntpd users are often found to have a boot-time call to ntpdate anyway! -jim With one clock, you know what the time is. With two clocks, you are never sure ...
