Has any seen the following? The Win7 clock ticks of 60s in 47s. Reproducible 100% on multiple machines. Happens on Win7, but not XP. This made me think of Viridian, but disabling Viridian didn''t change anything. Also happens with one or two CPUs in the DomU. DomU VPUs are pinned to CPUs 0 -> 0, 1 -> 1, etc. Any ideas? DomU: Win7 Dom0: 2.6.38 PVOPs, Ubuntu 11.04 Xen: 4.0.1 --- Tom Goetz tom.goetz@virtualcomputer.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
We''ve tracked this down further an it seems to be an issue with the virtual HPET. Some difference between 3.4.2 and 4.0.1 results in Win7 clock running fast. The lower the programmed frequency the more accurate the Win7 clock is. HPET frequency vs time for Win7 clock to tick off 60s: 1ms 60s 10ms 50s 15ms 46s In Win7 the ''rate adjustment'' column of the HalpHpetClockTable is zero for all frequencies. Our current working theory is that an issue at startup is causing the error calibration to fail or not happen resulting in larger errors at larger frequencies. On Jun 14, 2011, at 9:05 AM, Tom Goetz wrote:> Has any seen the following? > > The Win7 clock ticks of 60s in 47s. Reproducible 100% on multiple machines. Happens on Win7, but not XP. This made me think of Viridian, but disabling Viridian didn''t change anything. Also happens with one or two CPUs in the DomU. DomU VPUs are pinned to CPUs 0 -> 0, 1 -> 1, etc. > > Any ideas? > > DomU: Win7 > Dom0: 2.6.38 PVOPs, Ubuntu 11.04 > Xen: 4.0.1--- Tom Goetz tom.goetz@virtualcomputer.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Tom, At 09:18 -0400 on 16 Jun (1308215917), Tom Goetz wrote:> We''ve tracked this down further an it seems to be an issue with the virtual HPET. Some difference between 3.4.2 and 4.0.1 results in Win7 clock running fast. The lower the programmed frequency the more accurate the Win7 clock is. > > HPET frequency vs time for Win7 clock to tick off 60s: > 1ms 60s > 10ms 50s > 15ms 46sHave you been able to reproduce this on 4.1 or 4.2-unstable? The Win7 clock seems to be running at the right speed for me on unstable, just by booting win7 (sp1, 64-bit) and bringing up the desktop clock. Or do I need to do something in particular to change the granularity to 1ms? Tim.> In Win7 the ''rate adjustment'' column of the HalpHpetClockTable is zero for all frequencies. Our current working theory is that an issue at startup is causing the error calibration to fail or not happen resulting in larger errors at larger frequencies. >-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Jun 27, 2011, at 8:56 AM, Tim Deegan wrote:> Hi Tom, > > At 09:18 -0400 on 16 Jun (1308215917), Tom Goetz wrote: >> We''ve tracked this down further an it seems to be an issue with the virtual HPET. Some difference between 3.4.2 and 4.0.1 results in Win7 clock running fast. The lower the programmed frequency the more accurate the Win7 clock is. >> >> HPET frequency vs time for Win7 clock to tick off 60s: >> 1ms 60s >> 10ms 50s >> 15ms 46s > > Have you been able to reproduce this on 4.1 or 4.2-unstable? The Win7 > clock seems to be running at the right speed for me on unstable, just by > booting win7 (sp1, 64-bit) and bringing up the desktop clock. Or do I > need to do something in particular to change the granularity to 1ms? > > Tim. > >> In Win7 the ''rate adjustment'' column of the HalpHpetClockTable is zero for all frequencies. Our current working theory is that an issue at startup is causing the error calibration to fail or not happen resulting in larger errors at larger frequencies. >>I resolved the issue. Our brand new Qemu from upstream was emitting interrupts for the PIC. The extra timer interrupts were making time go faster. Thanks for replying. --- Tom Goetz tom.goetz@virtualcomputer.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel