Non-VM use case: The BeagleBone Black has no RTC, so -j could be
useful for cheap little ARM development boards.

On Wed, Sep 4, 2013 at 5:58 AM, Reyk Floeter <> wrote:
> On Wed, Sep 04, 2013 at 08:45:25AM -0400, Ted Unangst wrote:
> > > Bah.  I tend to turn ntpd off and rely on the internal clock
> > > synchronization of the hypervisor.  But fixing ntpd inside VMs would
> > > probably be a big win.
> >
> > Can you explain what you do? I have a vmt timedelta sensor that shows
> > host time, but how do you sync the openbsd clock to that?
> >
> let the host sync the system clock and hope that it doesn't run off
> ... but you're right, having a working ntpd would be much better.
> > > I don't like the fact that it would require another button.  Couldn't
> > > ntpd just detect this automatically?  Maybe by detecting that it is
> > > running inside a VM, or by whatever else?
> >
> > I think there is resistance to anything that treats VM differently. I
> > tend to agree. This is a more generic problem of the clock failing to
> > keep up, and can affect real hardware as well.
> Can you freeze and continue any other non-VM system?  Is it comparable
> with suspend/resume?  If not, than it is a special case that could be
> handled without being scared about a "VM-specific" option.  For
> example: The timedelta sensor could tell userland that it "might
> jump".  ntpd would pick it up from vmt automatically.
> I think that adding another button is worse.  It is already annoying
> to decide if I want to run ntpd with -s or not.  Now it would add -j
> and -s.  What combination is the best for my system?  Who knows?
> Reyk

Reply via email to