Beth Kon wrote:
> On Mon, 2008-10-27 at 12:49 +0200, Dor Laor wrote:
>   
>> Beth Kon wrote: 
>>     
>>> On Fri, 2008-10-17 at 16:49 +0100, Jamie Lokier wrote:
>>>   
>>>       
>>>> Beth Kon wrote:
>>>>     
>>>>         
>>>>> Clock drift on Linux is in the range of .017% - .019%, loaded and unloaded. I
>>>>> haven't found a straightforward way to test on Windows and would appreciate
>>>>> any pointers to existing approaches.
>>>>>       
>>>>>           
>>>> Is there any reason why there should be any clock drift, when the
>>>> guest is using a non-PIT clock?
>>>>
>>>> I'm probably being naive, but with 32-bit or 64-bit HPET counters
>>>> available to the guest, and accurate values from the CMOS clock
>>>> emulation, I don't see why drift would accumulate over the long term
>>>> relative to the host clock.
>>>>     
>>>>         
>>> I was measuring with ntpdate, so the drift is with respect to the ntp
>>> server pool, not the host clock. But in any case, since timer interrupts
>>> and reads of the hpet counter are at the mercy of the host scheduler
>>> (i.e., the qemu process can be swapped out at any time during hpet read
>>> or timer expiration), I'd guess there would always be some amount of
>>> inaccuracy. Also, qemu checks for timer expiration (qemu_run_timers) as
>>> part of a bigger loop (main_loop_wait), so the varying amounts of work
>>> to do elsewhere in the loop from iteration to iteration would also
>>> introduce irregular delays.
>>>   
>>>       
>> This is exactly why hpet as the other clock emulation in qemu (pit,
>> rtc, pm?) need
>> to check whether their irq was really injected. Gleb sent patches for
>> the rtc, pit.
>> The idea is to check with the irq chip if the injected irq was really
>> successful.
>>
>>     
> I assume these are the patches you're referring to?
> http://thread.gmane.org/gmane.comp.emulators.kvm.devel/18974/focus=18977
>
>   
Yap, Gleb just resent it.
> Looks like they were never merged. Does anyone know the history on that?
> Also, HPET generates edge-triggered interrupts (as dictated by Linux and
> Windows) so I'm not sure if this scheme could work for it.
>   
Right, I think if this time drift fix approach is accepted, it should 
also be implemented
for qemu_irq_pulse too.
>> Dor
>>