Well I've implicated timed(8) and nailed it to a master clock on the
network and it seems to be holding, so far so good! I look at using this
solution as applying band-aid im hoping to find out why this problem
happens in the first place. If anyone has any ideas let me know.

Thanks for the input every one!

Justin B

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Christopher Vance
Sent: Wednesday, June 21, 2006 12:25 AM
To: Adrian Close
Cc: Justin Blackmore; misc@openbsd.org
Subject: Re: Clock Drift - VMWare

On Wed, Jun 21, 2006 at 02:45:01PM +1000, Adrian Close wrote:
>On Tue, 20 Jun 2006, Justin Blackmore wrote:
>
>>Im running several OpenBSD 3.9 VM's on a GSX server and the clocks on
>>the OBSD vm's drift pretty bad, the real time host hardware clock is
>
>How much drift?  The guest "hardware" clock generally won't be stable 
>enough for NTP to keep things in sync (it might look like it's OK for a

>bit, but it won't be).
>
>You might be able to use the Linux vmware-guestd tool (I haven't tried
on 
>OpenBSD), which will sync the time to the host hardware if you ask it
(but 
>you need X11 to config that, from memory).
>
>I once had a GSX setup where guest hardware clocks typically ran at 1/3
- 
>1/10th of realtime, and sped up when the guest OS was eating lots of
CPU, 
>but that doesn't sound like what you have...

I don't have GSX, but I'm running some of my OpenBSD under WS5.5.1 on
a Linux amd64 (Dapper), and have clock drift there.  vmware says it's
at least partly due to CPU speed shifting on the underlying hardware.

For my limited purposes, frequent usage of rdate is adequate.

Did you consider trying timed, with master nailed to one of the
machines which can do ntp right?

-- 
Christopher Vance

Reply via email to