On Fri, 4 Jul 2003, Robert Bragg wrote: > My point was (I still think this is correct) that if his setup is > resulting in his clock getting out of sync on a daily basis, by 20-30 > minutes then he has bigger problems to think about before he starts > playing with ntpd.
True, true.. I stopped using NTPd because of this (it gave up like one time in a week becuase the lag was too large). I'm back to syncing time with home-made perl scripts instead. Although, what to do when it seems it is the system *software* that seems to mess up time and there seems to be no explanation as to why? These are the explanations I've heard so far for the lagging time behavior: * It's the power-save functionality of the kernel messing time up (No it isn't, problem remains unchanged no matter if APM and APIC is enabled or disabled) * It's a hardware error (no it isn't, since hwclock shows the correct time) * It's a bug in the gnome clock applet (no it isn't, since I run KDE, and besides the problem is the same in console mode) * It's a problem with settings of IDE disks and too aggressive hdparm settings, with the result that the system doesn't have the resources left to call the clock interrupt often enough (nope, I have a system entirely built on SCSI. This one might still be true some similar way though, but I don't know how to check it) * You haven't enabled RTC or RTC isn't readable (It is, I checked. Besides VMWare complains loudly if RTC isn't available, and since VMWare keeps quiet I think I did right) If someone else have any theories - no matter how far out, I will even check for evil green goblins sitting in the chassis messing with the clock chip - I will sure test them. // Joel -- [EMAIL PROTECTED] mailing list
