Chuck Swiger wrote:
> It looks like two or more of your upstream NTP sources disagree about 
> time to such an extent that they are swinging your clock back and 
> forth.  Either that, or maybe your mainboard's hardware clock is busted.

The disagreement was maybe because I was using the default config and it 
automagically chose quite a distant servers.

Now I configured ntpd to be client to only one local well adjusted 
server and started kernel and userland build. The frequency error, which 
is my concern, happened again:

Aug 14 23:14:40 mme ntpd[8859]: ntpd 4.2.0-r Mon Aug  1 13:09:50 CEST 
2005 (1)
Aug 14 23:14:40 mme ntpd[8859]: precision = 1.000 usec
Aug 14 23:14:40 mme ntpd[8859]: kernel time sync status 0040
Aug 14 23:14:40 mme ntpd[8859]: frequency initialized 211.539 PPM from 
/var/db/ntp.drift
Aug 14 23:22:12 mme ntpd[8859]: time reset +1.662649 s
Aug 14 23:22:12 mme ntpd[8859]: kernel time sync disabled 0041
Aug 14 23:45:53 mme ntpd[8859]: time reset +0.262294 s
Aug 14 23:45:53 mme ntpd[8859]: kernel time sync enabled 0001
Aug 14 23:54:30 mme ntpd[8859]: frequency error 512 PPM exceeds 
tolerance 500 PPM
Aug 15 00:09:33 mme ntpd[8859]: time reset +0.137555 s
Aug 15 00:14:56 mme ntpd[8859]: frequency error 512 PPM exceeds 
tolerance 500 PPM

Is it safe to ignore the frequency errors? What does the 'hardware clock 
is busted' mean?

Thanks,

r.