Timekeeping in stable/9

Alexander Motin mav at FreeBSD.org
Sat Jan 21 12:30:58 UTC 2012


Hi.

On 01/21/12 11:18, Martin Sugioarto wrote:
> Am Wed, 18 Jan 2012 07:50:49 +0100
> schrieb Martin Sugioarto<martin at 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


More information about the freebsd-stable mailing list