On Tue, 06 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <QbVTj.7000$zw.4525@trnddc04>, Jack Snodgrass wrote:

>I can't figure ntpd out.

Well, your subject is slightly wrong - you want to be looking for

-rw-rw-r-- 1 gferg ldp 43295 Nov 18 2005 TimePrecision-HOWTO

but the NTP package should have a lot of documentation in it. What does
'rpm -qd ntp' show you?

>It starts and runs... it just doesn't keep my non-stable-clock system up
>to date.

2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI. D. Mills. October 1996. (Format: TXT=48620 bytes) (Obsoletes
RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL)

4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
OSI. D. Mills. January 2006. (Format: TXT=67930 bytes) (Obsoletes
RFC2030, RFC1769) (Status: INFORMATIONAL)

There's the basic RFCs. However, the client isn't meant to handle
time errors greater than 500 ppm (about 44 seconds a day). The common
piece of crap oscillator used in computers has a _typical_ worst case
specification of 200 ppm.

>If I let my vmware guest run for 24 hours, the time on the vmware
>guest gets off by about 2 hours.

And there's your problem. You're not running it on real hardware. A
modern operating system keeps track of time in a PC type of system by
using the IRQ 0 interrupt (a divider is programmed to cause a set
number of interrupts per second). In Linux, it depends on how your
kernel was compiled, but this can be 100, 500, or 1000 interrupts
per second. (Run the command 'cat /proc/interrupts' ten seconds apart
to see which yours is running at.) You're running a fake computer
using vmware - so which O/S is supposed to get the IRQ0?

>Currently, I have ntpd disabled and I have a cron job that runs every
>minute and runs ntpdate to keep the time accurate...

You might have better luck running 'hwclock' to set the clock from the
hardware (CMOS) clock, but what-ever.

>I thought that ntpd was supposed to be able to do this....

ntp can handle 500 ppm (0.05%) - not 2/24 (8.33%).

>If ntpd can't keep the time on the local box accurate... what's the
>purpose of it? I've had this issue with ntpd for years... I've always
>had to resort to disableing it and running ntpdate from cron.

Loose the fake computer. What you are seeing is that the kernel is
unable to keep even an approximation of time, mainly because the
mechanism to measure time (those interrupts) are being blocked or
ignored. You _MIGHT_ have better luck using a kernel compiled for
a 100 Hz interrupt, but I really doubt it.

Old guy