Dear Frank,
Thank you so much for the thorough explanations!
Sorry for my late reply as I was tesing with NuttX guest with qemu-system-arm
v9.2 on Ubuntu 22.04 x64 edition, using the emulated Generic Timer.
My test includes two parts:
- A NuttX app sends CAN data within QEMU, with usleep(S) between the ops.
- Use candump on Ubuntu host to check CAN timestamp delta (-t d)
I collected logs of 1000 operations and got statistics like
usleep mean(ms), stdev(ms)
1 10.530 0.198
5000 5.558 0.229
1000 1.187 0.071
See my other notes embedded below.
Regards,
yf
On Wed, 2025-03-05 at 10:55 +0100, Frantisek Rysanek wrote:
> Dear YangFeng,
>
> thanks for the question :-)
>
> Timekeeping is a complex topic.
> Could you perhaps add more detail on what you are trying to achieve?
> Linux offers various API functions for timing, in the kernel and in
> the user space - though oops, you haven't mentioned what guest VM you
> are considering...
> Different timing functions serve different purposes, and under the
> hood, they tap into different hardware "resources" available (timers,
> counters, whatever). Such as, you can ask the guest OS:
> - "wake me up after 20 ms, starting from now"
> - Or, you can ask it "wake me up at 13:07:21.057 precisely".
> - Or, you may merely want to know "what time is it, right now as I'm
> asking?"
>
It seems that I am asking the first case.
> Note that QEMU/KVM comes accompanied by a set of guest-side drivers.
> One of them presents a virtual PHC. This will provide a fairly
> precise answer to the question "what time is it right now", tapping
> into the host's timebase and hardware. Ordinarily, you would let your
> guest OS sync its timebase to that PHC, and your applications running
> in the guest would then get precise time just by asking their OS in
> the standard way.
>
>
> If the question really is, "how precise are the emulated HW timers",
> e.g. the PC AT i8254 programmable timer, or some HPET (not sure if
> this even gets emulated) - obviously that emulation is not so rosy.
> Its precision boils down to event (interrupt) handling latency and
> jitter. Things are relatively good if you have a whole CPU core
> reserved to the particular VM guest instance - but if multiple guest
> VM instances share the time of a physical host CPU core, guess what's
> likely to happen... Same thing if the HV/host OS instance is busy,
> especially if busy serving other interrupts.
>
Yes, I was wondering how good the emulated Arm Generic Timer is.
I guess the observed time intervals are mainly contributed by usleep(), time for
send operations, time for data traveling, plus jitters from scheduling. Anything
else?
> Please note that the PIT and HPET exist just once for the whole
> physical machine (are a part of the chipset) and therefore need to be
> emulated for each VM guest instance.
> Modern x86 CPU's supposedly also have the "local APIC timer" - and
> the LAPIC supposedly is private to a CPU core. Not sure to what
> extent the LAPIC is beneficial to virtualization - you could argue
> that the VM guest could use it directly, if the CPU core is
> reserved/dedicated to a particular guest. Yet I wouldn't bet on this,
> and for the general case, the host / HV will likely want to keep a
> handle on the LAPIC timer per core (and maybe make it available to
> the VM guest through some virty encapsulation mechanism).
> The one hardware counter that IMO needs no virty wrappers, is the TSC
> :-) It just counts forward, at some constant frequency, derived by
> multiplication from the physical CPU's external reference base.
>
>
> I don't quite understand your note about the TCG *accelerator*.
> I'm just a fellow user of QEMU, not conversant in the guts.
> A quick google is telling me that the TCG is the code generator
> inside QEMU, that's able to emulate instructions not supported by
> your physical CPU.
Yes, I used TCG to mean that I was not using KVM.
> In that vein, for optimal results, I would suggest to set the
> emulated CPU to "host" (=native). This should allow your guest OS to
> adapt to your host CPU's physical capabilities, thus all guest
> instructions get executed natively by bare metal, and thus the need
> to actually emulate instructions via the TCG gets minimized...
>
> Frank
>
> https://www.vmware.com/docs/vmware_timekeeping
> https://wiki.osdev.org/APIC_Timer
> https://airbus-seclab.github.io/qemu_blog/tcg_p1.html
>
>
>
> Subject:Timer quality
> From: Yanfeng Liu
> To: qemu-discuss@nongnu.org
> Date sent: Wed, 05 Mar 2025 15:37:30 +0800
>
> > Dear experts,
> >
> > I am wondering how the precision of timers are with QEMU on x64 Ubuntu
> > Linux and TCG accelerator?
> >
> > Regards,
> > yf
> >
> >
> >
> >
>
