Hi guys, Has anyone else noticed the tendency for 9.0-R to be unable to accurately keep time? I've got a couple of machines that have been upgraded from 8.2 that are struggling, in particular a Virtual box guest that was fine on 8.2, but now that's its been upgraded to 9.0 counts at anything from 2 to 20 seconds per 5 second sample, the result is similar with HPET, ACPI-fast and TSC. I also have physical boxes which new seem to drift quite substantially, ntpd cannot keep up and as these boxes need to be able to report the time relatively accurately, it is causing problems with log times and such... Any suggestions most welcome! Thanks, J
Am Tue, 17 Jan 2012 20:12:51 +0000 schrieb Joe Holden <lists@rewt.org.uk>:> Hi guys, > > Has anyone else noticed the tendency for 9.0-R to be unable to > accurately keep time? I've got a couple of machines that have been > upgraded from 8.2 that are struggling, in particular a Virtual box > guest that was fine on 8.2, but now that's its been upgraded to 9.0 > counts at anything from 2 to 20 seconds per 5 second sample, the > result is similar with HPET, ACPI-fast and TSC.Hi Joe, 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. You can perhaps try yourself and confirm, if it's the disk I/O that influences timers. I somehow don't like the hard disk behavior. It makes desktop unusable in some situations (mouse pointer skipping, applications lock for several seconds).> I also have physical boxes which new seem to drift quite > substantially, ntpd cannot keep up and as these boxes need to be able > to report the time relatively accurately, it is causing problems with > log times and such...Not sure about physical boxes. I have not taken a look at this, yet. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 834 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120118/bf96913a/signature.pgp
On Tue, 2012-01-17 at 20:12 +0000, Joe Holden wrote:> Hi guys, > > Has anyone else noticed the tendency for 9.0-R to be unable to > accurately keep time? I've got a couple of machines that have been > upgraded from 8.2 that are struggling, in particular a Virtual box guest > that was fine on 8.2, but now that's its been upgraded to 9.0 counts at > anything from 2 to 20 seconds per 5 second sample, the result is similar > with HPET, ACPI-fast and TSC. > > I also have physical boxes which new seem to drift quite substantially, > ntpd cannot keep up and as these boxes need to be able to report the > time relatively accurately, it is causing problems with log times and > such... > > Any suggestions most welcome! > > Thanks, > JI finally got a 9.0 generic build done today and I've been watching the timekeeping on 3 systems and they're all doing just fine. Two of the systems are performing pretty much identically to how they did on 8.2; the clock frequency correction calculated by ntpd differs by less than 1ppm. On the other system the kernel timekeeping routines are now choosing to use a different clock so I don't get a direct comparison of the old vs new drift rate, but the drift is still reasonable (100ppm now, used to be around 88, on an old 300mhz MediaGx-based system). I haven't had time yet to learn about the new eventtimer stuff in 9.0, but I know you can get some info on the choices it made via sysctl kern.eventtimer. Before 9.0 I'd check sysctl kern.clockrate and vmstat -i and make sure the chosen clock is interrupting at the right rate, but now with the eventtimer stuff there's not an obvious correlation between hz and profhz and stathz and any particular device's interrupt rate, at least for some clock choices (on the old MediaGx system without ACPI or HPET it seems to work more like it used to). -- Ian
Hi. On 01/21/12 11:18, Martin Sugioarto wrote:> Am Wed, 18 Jan 2012 07:50:49 +0100 > schrieb Martin Sugioarto<martin@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