On Monday, 06.07.2015 at 10:35, Antti Kantee wrote: > While that may be a fix, how can that even in theory be a fix for > the guest clock running at 2/5 speed compared to the real world??
The problem I was trying to fix was sleeps being way too long on x86-64 (as reported by the test program). > Testing confirms that the problem is still there. I also tested > 32bit qemu, and I see the problem there too. Regarding the wall clock, I see no problems on my system (2011 vintage Sandy Bridge with invarant TSC). In fact, I've had a "php -S" unikernel running for some time now and the wall clock is exactly the same to the host clock. You did mention that you're testing on a Core 2 laptop, right? What does cat /proc/cpuinfo say on your system? Also, as an experiment, can you try and boot either variant of clock_test.bin directly from GRUB, while running the system on AC? > Also, qemu now > consumes ~7% host CPU for a program which does "sleep(1000);". That > is way way too high for everything to be peachy. Not really. Don't forget that rumpclk is trying to run at 100 Hz, so at the moment you'll never run into really long sleeps anyway.
