k...@munnari.oz.au (Robert Elz) writes:
> | This is not to be confused with the kernel idea of wall-clock time
> | (i.e. what date reports). wall-clock time is usually maintained
> | by hardware seperated from the interrupt timers. The 'date; sleep 5; date'
> | sequence therefore can show that
Date:Sun, 30 Jul 2017 16:04:38 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| There are slower emulated systems that don't have these issues. (*)
Yes, that it is not qemu's execution speed was (really, always) becoming
obvious.
| If the hos
g...@gson.org (Andreas Gustafsson) writes:
>Frank Kardel wrote:
>> Fixing that requires some more work. But I am surprised that the qemu
>> interrupt rate is seemingly somewhat around 50Hz.
It shouldn't have a problem on Linux.
--
--
Michael van Elst
Internet: m
k...@munnari.oz.au (Robert Elz) writes:
>kern/43997 is the "qemu is too slow, clock interrupts get lost, timing
>gets all messed up" problem that plagues many of the ATF tests that kind
>of expect time to be maintained rationally.
There are slower emulated systems that don't have these issues. (*
>> # 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).
> [...], but an error of a factor 2 looks suspicious.
This is tickling old memories. I think I ran into a case where
requesting timer ti
Frank Kardel wrote:
> 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 tha
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-bas
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 mi
Could you check which timecounter is used under qemu?
sysctl kern.timecounter.hardware
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 t
Date:Sun, 30 Jul 2017 13:01:50 +0300
From:Andreas Gustafsson
Message-ID: <22909.44686.188004.117...@guava.gson.org>
| I don't think the slowness of qemu's emulation is the actual cause of
| its inability to simulate clock interrupts at 100 Hz.
Yes, I was wonderin
Robert Elz wrote:
> I want to leave /bin/sh to percolate for a while, make sure there are
> no issues with it as it is, before starting on the next round of
> cleanups and bug fixes, so I was looking for something else to poke
> my nose into ...
>
> [Aside: the people I added to the cc of this mes
I want to leave /bin/sh to percolate for a while, make sure there are
no issues with it as it is, before starting on the next round of
cleanups and bug fixes, so I was looking for something else to poke
my nose into ...
[Aside: the people I added to the cc of this message are those who have
added
12 matches
Mail list logo
