Re: NTP problem for virtual RHEL 4 server on VmWare

We adjusted the kernel parameters this morning, and the result looks
promising:


13 Nov 08:01:02 ntpdate[6253]: adjust time server 1.2.3.4 offset 0.041978
sec
13 Nov 09:01:01 ntpdate[14110]: adjust time server 1.2.3.4 offset -0.426118
sec
13 Nov 10:01:02 ntpdate[24901]: adjust time server 1.2.3.4 offset -0.151613
sec
13 Nov 11:01:01 ntpdate[3253]: adjust time server 1.2.3.4 offset 0.244806
sec
13 Nov 12:01:01 ntpdate[14023]: adjust time server 1.2.3.4 offset 0.256945
sec
13 Nov 13:01:02 ntpdate[25138]: adjust time server 1.2.3.4 offset -0.058973
sec
13 Nov 14:01:01 ntpdate[3482]: adjust time server 1.2.3.4 offset 0.144722
sec
13 Nov 15:01:01 ntpdate[12936]: adjust time server 1.2.3.4 offset -0.019486
sec


I'll keep monitoring it, but if nothing else comes up I think I'll settle
for this solution.

Thansk for all the help.


Regards,
Kenneth


On 11/13/08, Kenneth Holter <kenneho.ndu@xxxxxxxxx> wrote:


Interesting observation. Our troublesome VM has been running for quite a
log while, though, and it still seems quite unstable. We just rebooted it
with the kernel parameters mentioned in http://kb.vmware.com/kb/1006427 (thank
you Mr. Dill), and I'll post the results back here in a day or two.
Hopefully it will solve our problem, even thogh it didn't solve yours.

What puzzles me is why this VM drifts so much, while most of our other VMs
doens't (at least not more than NTPd can handle).


On 11/12/08, Eric Sisler <lbylnxgek@xxxxxxxxx> wrote:

On Fri, Nov 7, 2008 at 2:49 AM, Kenneth Holter <kenneho.ndu@xxxxxxxxx
wrote:

Hei.


One of our RHEL 4 servers running on VmWare has a quite serious NTP
problem.
I know that NTP can be an issue when running red hat boxes on VmWare, so
as
a fix I put this small script in a file in /etc/cron.hourly:



Early on I went through the frustrations with time & NTP problems on RHEL
4
virtual machines. I've used a number of the earlier suggestions,
including
various boot time & VMware configuration options. I even went so far as
to
compile a custom kernel with the clock frequency set back to 100, as it
was
for the 2.4.x kernels. Overall it didn't seem like any of the boot time
or
VMware config options made that much difference. Recompling the kernel
works, but gets to be a lot of overhead after awhile.

Now for the odd part: Currently my RHEL4 VMs have time sync enabled in
the
VMware config file & also have NTP running. It seems that the longer NTP
runs, the more accurate the time gets on the VM. When booting a "new" VM,
it wasn't uncommon for NTP to adjust the time by 20-30 seconds. Once the
VM
gets a bit "older" & NTP has been running longer, when rebooting the VM
clock adjustment goes down to around 5-6 seconds. I suspect part of this
has to do with the frequency & adjustment history recorded by NTP.

The updated VMware KB may be of some help as well. Good luck!

-Eric
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list



--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

Relevant Pages

  • Re: NTP problem for virtual RHEL 4 server on VmWare
    ... One of our RHEL 4 servers running on VmWare has a quite serious NTP ... compile a custom kernel with the clock frequency set back to 100, ... VMware config options made that much difference. ... gets a bit "older" & NTP has been running longer, when rebooting the VM ...
    (RedHat)
  • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
    ... Uses NTP to modify the clock frequency value rather then just ... > adjustment, which should be applied every f cycles. ... Your design seems to suggest keeping an NTP calculated reference time ...
    (Linux-Kernel)
  • Re: Dual-core systems - AMD - Windows Vista
    ... What I can say right now is that the default tick adjustment value is ... The test machine is a Intel Pentium D 3 GHz with Windows Vista ... in order to test the accuracy of NTP the Meinberg time service was ...
    (comp.protocols.time.ntp)
  • Re: [why oom_adj does not work] Re: Linux killed Kenny, bastard!
    ... calculate adjustment used to properly select oom-killed process? ... So, effectively, oom adjustment does not work. ... Having a name in the kernel is like building a hit-list, ...
    (Linux-Kernel)
  • Re: Monitoring the leap second tonight
    ... While the kernel does step the clock backward, the clock reading routine should remember the last reading and not allow a backward adjustment, unless more than two seconds. ... As for the leap itself, all the radios, FreeBSDs, Solariba, Ultrax and Alphae leaped the leap correctly. ... The CDMA receiver with embedded Linux went bonkers; it took the leap 24 hours ago and stayed that way until after the leap tonight. ... I'm not sure what this means; the CDMA takes its cue from GPS and the CDMA receiver hands off to NTP. ...
    (comp.protocols.time.ntp)