[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Qemu on Windows (with haxm and whpx), minimal Ubuntu,

From: Michael Fritscher
Subject: Re: [Qemu-discuss] Qemu on Windows (with haxm and whpx), minimal Ubuntu, SLIRP and OpenVPN: very slow
Date: Tue, 14 May 2019 09:36:29 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

Am 13.05.2019 um 23:41:25 schrieb Michael Fritscher:
On 13.05.19 23:16, Jakob Bohm wrote:
On 13/05/2019 16:35, Michael Fritscher wrote:
Am 13.05.2019 um 16:10:33 schrieb Michael Fritscher:
   Am Montag, 13. Mai 2019 15:25 CEST, Michael Fritscher
<address@hidden> schrieb:
Am 13.05.2019 um 10:32:48 schrieb Michael Fritscher:
Good day,

Host: Windows 7 and 10 64 bit, Skylake+ CPUs
Qemu Version: 3.1 (4.0 isn't available yet on
Accelerators: HAXM and WHPX
Guest: Ubuntu 18.04.2 64 bit, minimal install
Guest's tasks: OpenVPN, iptables, tc

-machine q35,accel=kvm:hvf:whpx:hax:tcg
-m 512
-smp 1
-rtc base=utc
-vga std
-device virtio-net,netdev=natted,mac=00:50:56:00:08:00
-monitor tcp:localhost:4444
-kernel vmlinuz
-initrd initrd.img
-append "boot=casper textonly quiet nosplash nofb fb=false pti=off
spectre_v2=off l1tf=off nospec_store_bypass_disable noprompt"

(the iso is a casper livecd, but I start the linux kernel directly
because of boot speed)

It is slow...
While a openssl speed -elapsed -evp aes-128-cbc is ok (500MB/sec
and beyond), OpenVPN struggles.
I get 70% virtual CPU usage , mostly on OpenVPN and system load
while transfering 1-2 MB/s with a UDP video stream. The measured
delay is also
rather spiky and is about 30...40 ms. On the host I get a cpu
usage of about 10% (=almost a core) I see this both on the server
and the client

On the player edition of the big commercial player, the results
are _much_ better (10% virtual CPU usage, delay of 4-6 ms)

How can I further debug this? Do you know any knobs I can try?
Slirp, while there are warnings of being slow, doesn't seem to be
the culprit as
I can get easily >>10 MB/s through it. And I see the big CPU usage
of OpenVPN

Best regards,
Michael Fritscher

Hi again,

after a bit of digging, openVPN seems to call read_hpet with about
1 kHz, which is, regarding to the program perf, the main culprit.
Is a call
rate of this frequency normal and qemu is just very slow to handle
them, or is there another problem?

Compare the boot-up dmesg of the guest OS kernel in the two scenarios.
Assuming read_hpet is a kernel-level function, it may simply be that
on VMware, the kernel or driver chooses to use a different "hardware"
mechanism to implement whichever system call is being called 1000
times per second.

Also note, that video stream software is more likely than OpenVPN to
be making extremely frequent timer checks (UDP media streams time
packet arrivals to manage buffering and smooth over the content in
lost packets).

Another frequent user of timing calls is performance checking tools.


The thing is, on VMWare I see no hpet_read calls, the most called
function is reading from the network card - and I have _way_ more called
syscalls on VMWare (30k on VMWare vs. 9k on qemu in 5 seconds)... Also,
hpet itself isn't the culprit here as if I disable hpet I get the same
problem on acpi_pm_read... And I see (with perf) that they are always
called from openVPN. Sadly I didn't managed to get a backtrace jet to
further analyse why these functions are called so much from OpenVPN yet.

The PCs are directly connected via a GBit switch. Also, the VM does only
do OpenVPN (+iptables + tc), the creation and reception of the stream is
done completely the host.

I've uploaded the perf data and the parsed log of perf here:
https://mifritscher.de/austausch/openvpn - perhaps I simply missread it.

Best regards,
Michael Fritscher

Good morning,

I've uploaded the perf file from VMWare for comparison under https://mifritscher.de/austausch/openvpn/vmware/ . Additionally, I've uploaded the dmesg output using VMWare and Qemu.

One interesting thing: It does not always happen, and if it doesn't happen I can provoke it playing with the priority, CPU affinity etc of the qemu process. So it seems to be really a timing problem which can be provoked by scheduling issues on the host?

Best regards,
Michael Fritscher

ZfT - Zentrum für Telematik e.V.
Michael Fritscher
Magdalene-Schoch-Straße 5
97074 Würzburg
Tel: +49 (931) 615 633 - 57
Fax: +49 (931) 615 633 - 11
Email: address@hidden
Web: http://www.telematik-zentrum.de

Prof. Dr. Klaus Schilling, Prof. Dr. Andreas Nüchter,  Hans-Joachim Leistner
Sitz: Gerbrunn
USt.-ID Nr.: DE 257 244 580, Steuer-Nr.:  257/111/70203
Amtsgericht Würzburg, Vereinsregister-Nr.: VR 200 167

Attachment: michael_fritscher.vcf
Description: Vcard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]