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 <r...@openbsd.org> 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 >
