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

[mlelstv%serpens.de@localhost (Michael van Elst)]

kre%munnari.OZ.AU@localhost (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. (*)


>The problem is really (again from the PR)

>	The routines sleep(3), usleep(3), and nanosleep(2) wake-up based on the 
>	occurrence of clock ticks.  However, the timer interrupt routine
>	determines the actual absolute time.

If the host misses interrupts, time in the guest just passes slower
than real-time. But inside the guest it is consistent.

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 10 seconds passed.


The problem with qemu is that it's running on a NetBSD host and
therefore cannot issue interrupts based on host time unless the
host has a larger HZ value.

With host and guest running at HZ=100, it's obvious that interrupts
mostly come just too late and require two ticks on the host, thus
slowing down guest time by a factor of two.


(*) This emulator derives timer information from the emulation itself.
I.e. after N emulated cycles, the timers advances accordingly. If the
emulation is too slow, it may even skip timer values to keep pace.
Only when it is too slow to even adjust the timers once per HZ, you
see similar issues as with in qemu.

dummy# date; sleep 5; date
Sun Jul 30 18:01:23 CEST 2017
Sun Jul 30 18:01:28 CEST 2017

dummy# atf-run t_ldp_regen | atf-report
Tests root: /usr/tests/net/mpls

t_ldp_regen (1/1): 1 test cases
    ldp_regen: [48.646148s] Passed.
[48.646421s]

Summary for 1 test programs:
    1 passed test cases.
    0 failed test cases.
    0 expected failed test cases.
    0 skipped test cases.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."