Hi.
On 01/21/12 11:18, Martin Sugioarto wrote:
Am Wed, 18 Jan 2012 07:50:49 +0100
schrieb Martin Sugioarto<mar...@sugioarto.com>:
I can confirm this on VirtualBox. I've been running WinXP inside
VirtualBox and measured network I/O during downloads. It showed me
very high download rates (around 800kB/s) while it's physically
possible to download 200kB/s through DSL here (Germany sucks with
DSL, even in largest cities, btw!).
I correlated this behavior with high disk I/O on the host. That means
that the timer issues on the virtual host appear when I start a
larger cp job on the host. I also immediately thought that this has
something to do with timers.
I just want to add some information on this. I tested a few things with
VirtualBox yesterday.
I switched off ntpd on the host and tested if there are differences,
but the clock is working correctly on the host. I tested it a few times,
it is stable, as I expect it to be.
It seems to be rather a software problem with VirtualBox. I can see that
when the host is under heavy load (CPU!) the guest does not get enough
runtime to adjust the clock correctly. After a few minutes there has
been a difference of 50 seconds between the host and guest clock. And
furthermore, I don't quite understand how the real time clock works in
VirtualBox but it seems to slide in the different directions causing
weird results with progress bars on MS-Windows XP.
I just want to explain why I thought that I/O influences this. I have
got my hard disk encrypted, so it puts some load on the CPU, too.
If you want to test VirtualBox behavior, you can simple dd
from /dev/random and look at the weird results in VirtualBox.
I am not using VirtualBox right now, so I'll need to setup it to test
this. Meanwhile you could try to experiment with switching to different
timecounters and eventtimers. May be some change in 9.0 changed default
timecounter for you, causing the problem.
timecounter wrap should be the main cause of time drift (if timecounter
hardware is emulated correctly at all). Different timecounters have
different wrap periods that can be calculated by dividing
kern.timecounter.tc.X.mask on kern.timecounter.tc.X.frequency. In my
case there are: 300s for HPET, 5s for ACPI-fast, 2s for TSC and 55ms for
i8254. If system won't get timer interrupts within half of that time --
time will drift. Start from looking what you are using and how good it
is in your case.
--
Alexander Motin
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
