Hi Gene,
Given a stable clock in your box, which from the reports below I doubt, every 2 minutes would, I think, give results that are totally lost in the propagation delays of the net.
Actually the physical server is fine, only need to run ntpdate once per hour on it.
And this is contacting my firewall for the time, not the net. I have other servers synchronising off the same firewall without issues.
Really seems like something screws up running Fedora inside VMware GSX.
Everything else is running perfectly though, just the system clock is screwy. Windows in a virtual server on the same host server is fine.
This doesn't look like a tickadj correctable error to be truthfull unless you take tickadj down in the 6000 - 7500 range. This one
Well I'm slowly reducing it (currently at 9900) and this is what I am seeing now.
Feb 10 16:47:58 krusty ntpdate[9134]: step time server 202.173.151.129 offset -3.756325 sec
Feb 10 16:49:52 krusty ntpdate[9146]: step time server 202.173.151.129 offset -9.375502 sec
Feb 10 16:50:01 krusty ntpdate[9153]: adjust time server 202.173.151.129 offset -0.086756 sec
Feb 10 16:51:51 krusty ntpdate[9166]: step time server 202.173.151.129 offset -9.705495 sec
Feb 10 16:52:02 krusty ntpdate[9172]: adjust time server 202.173.151.129 offset -0.456918 sec
Looks quite promising, it's a lot closer than before.
Asking the next obvious question, do you have cpufreq enabled?
Um nope. No program found by that name although I did find cpufreq in the kernel modules but it isn't a loaded module according to lsmod.
There is also a cpuspeed ticked on in ntsysv so could that be an issue?
-- Regards, Peter Kiem
Zordah IT - IT Consultancy and Internet Services Ph: (0414) 724-766 Fax: (07) 3344-5827 Web: www.zordah.net Email: zordah@xxxxxxxxxx
