Re: Understanding PR kern/43997 (kernel timing problems / qemu)

[Frank Kardel <kardel%netbsd.org@localhost>]

Hi Andreas !

On 07/30/17 15:20, Andreas Gustafsson wrote:
> Frank Kardel wrote:
>> Could you check which timecounter is used under qemu?
>>
>> sysctl kern.timecounter.hardware
>
> # sysctl kern.timecounter.hardware
> kern.timecounter.hardware = hpet0
>
>> Usually the timecounters are hardware-based and have no relation
>> to the clockinterrupt. In case of qemu you might get a good
>> emulated timecounter, but a suboptimal clockinterupt.
>> If this is the case it helps to use the clockinterrupt
>> itself as timecounter for the wall clock time to avoid a discrepancy
>> between clockinterrupt-driven timeout handling and wall-clock time 
tracking.
>>
>> sysctl -w kern.timecounter.hardware=clockinterrupt
>
> # sysctl -w kern.timecounter.hardware=clockinterrupt
> kern.timecounter.hardware: hpet0 -> clockinterrupt
> # time sleep 10
>        10.02 real         0.00 user         0.00 sys
>
> This actually took 20 seconds of real time (manually timed with a
> stopwatch).
>
>> This is the opposite from deducing the missed clock interrupts
>> from the wall clock time and keeps timeout handling and in the 
emulation
>> observed wall-time synchronized no matter how slow
>> the clock-interrupts are - the emulated wall clock time will be
>> at the same rate.
>
> Right, but I would still rather see the bug fixed than worked around
> this way.
Fixing that requires some more work. But I am surprised that the qemu 
interrupt rate is seemingly somewhat around 50Hz.
Could it be a bug in qemu getting the frequeny not right. qemu should 
read the clock to get the frequencies right an possibly skip
usleeps less than i/HZ possibly managing an error-budget. I haven't 
looked into qemu at all, but an error of a factor 2 looks suspicious.

Frank