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) 10000 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 <yfliu2...@qq.com> > 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 > > > > > > > > >
