From: "Peter Kiem" <zordah@xxxxxxxxxx>
> I've kept on playing with tickadj and found out that 9000 seems to be
> the lowest that FC3 will go in my virtual server. However this seems to
> have slowed the clock down to within a couple of seconds gain every 2
> minutes
>
> Feb 11 10:41:56 krusty ntpdate[3687]: step time server 202.173.151.129
> offset -4.675165 sec
> Feb 11 10:42:01 krusty ntpdate[3693]: adjust time server 202.173.151.129
> offset -0.165226 sec
> Feb 11 10:43:58 krusty ntpdate[3705]: step time server 202.173.151.129
> offset -2.661458 sec
> Feb 11 10:45:57 krusty ntpdate[3720]: step time server 202.173.151.129
> offset -4.160441 sec
> Feb 11 10:47:59 krusty ntpdate[3738]: step time server 202.173.151.129
> offset -2.028393 sec
>
> Thinking that this might be within ntpd's tolerances now I turned off
> the 2 minute ntpdate and restarted ntp.
>
> Looks like ntpd still isn't working however:
> # ntpq -p
> remote refid st t when poll reach delay offset
> jitter
>
============================================================================
==
> fizban.zordah.n 0.0.0.0 5 u 3 64 377 0.948 14109.8
> 6480.31
>
> This could be important, even though the reach value is tell me it can
> reach the NTP server ntptrace is telling me a different story!
>
> # ntptrace 202.173.151.129
> 202.173.151.129: timed out, nothing received
> ***Request timed out
>
> Why is this?
Peter, if this is inside a VMWare virtual machine someone mentioned
there is a formal way to set it up to use the base machine's time.
Run ntp on the host OS and let VMWare use the host system's clock.
Otherwise you are going to live with a system VERY screwed up for
time.
{^_^}
