From owner-freebsd-stable@FreeBSD.ORG Sat Jan 21 12:30:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22546106566C for ; Sat, 21 Jan 2012 12:30:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A746D8FC14 for ; Sat, 21 Jan 2012 12:30:57 +0000 (UTC) Received: by eaai10 with SMTP id i10so597250eaa.13 for ; Sat, 21 Jan 2012 04:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8k0/romLOorcs63ujky1sHMCPnZYu862gLI1EB1tSqM=; b=VQ6ct9UvzRVDb5pQ64FeoxiuuJkgsjm9y6LfNn8H9L9Sqgk25wJZJc6lxaMyLQa6wE oSjLdB56veKkqMiz8cZ1lmMl7rWKso5YPiFcWWKA7ITaan9VBbzI2pkP+f76/iAl+pGL CtX3bTRYypuBjDtaNyfFZHC8ukbYhRFHkzV/U= Received: by 10.213.101.20 with SMTP id a20mr379729ebo.83.1327149056635; Sat, 21 Jan 2012 04:30:56 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n17sm25033547eei.3.2012.01.21.04.30.54 (version=SSLv3 cipher=OTHER); Sat, 21 Jan 2012 04:30:55 -0800 (PST) Sender: Alexander Motin Message-ID: <4F1AAFFD.7070303@FreeBSD.org> Date: Sat, 21 Jan 2012 14:30:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Sugioarto References: <20120118075049.289954e8@zelda.sugioarto.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: Timekeeping in stable/9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 12:30:58 -0000 Hi. On 01/21/12 11:18, Martin Sugioarto wrote: > Am Wed, 18 Jan 2012 07:50:49 +0100 > schrieb Martin Sugioarto: > >> 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