For me the timekeeping was visible after some uptime (few days to a bit over a week) where the clock was off by 30 minutes two many hours. ntpd could of course no longer correct that.
So if the machines are up for that long just running date should show this problem. If that's not it I guess we are heading for printf debugging and tcpdumping... On October 24, 2018 1:53:18 PM GMT+02:00, "Aaron A. Glenn" <[email protected]> wrote: >* Hrvoje Popovski <[email protected]> [2018-10-23 22:46]: >> On 23.10.2018. 21:41, Florian Obser wrote: >> > I'm currently on vacation and can't look into this soon. >> > >> > One thing that comes to mind: do these machines keep proper time or >are they having issues with timer interrupts stopping because of too >new KVM version and missing hypervisor flag (someone with access to a >real computer please chip in with a link to a thread where this has >been discussed before and the name of the KVM flag). >> > >> >> This link? >> https://marc.info/?l=openbsd-misc&m=151575775607633&w=2 > >I've seen this posting before, but I'm not confident this is the/an >issue. Also, I have zero access or visibility into the underlying >hypervisor. > >I did a quick `time sleep 1` test over all the problematic instances: > > 0m01.01s real 0m00.00s user 0m00.00s system > 0m01.07s real 0m00.00s user 0m00.04s system > 0m01.01s real 0m00.00s user 0m00.02s system > 0m01.00s real 0m00.00s user 0m00.00s system > 0m01.01s real 0m00.00s user 0m00.00s system > 0m01.00s real 0m00.00s user 0m00.00s system > 0m01.00s real 0m00.00s user 0m00.00s system > 0m01.02s real 0m00.00s user 0m00.00s system > 0m01.04s real 0m00.00s user 0m00.01s system > 0m01.01s real 0m00.00s user 0m00.01s system > > >Is there a better way to test for this from the guest? If absolutely >necessary, I can attempt to wade through various support desks to get >some details. > >Thanks
