summary refs log tree commit diff stats
path: root/results/classifier/118/performance/597351
blob: 57278a7d2132848a2bf04d62537b5e8484720a1c (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
performance: 0.968
graphic: 0.682
device: 0.648
semantic: 0.548
user-level: 0.514
architecture: 0.456
peripherals: 0.440
network: 0.415
mistranslation: 0.389
virtual: 0.332
socket: 0.313
x86: 0.190
PID: 0.182
permissions: 0.171
ppc: 0.163
hypervisor: 0.148
debug: 0.136
assembly: 0.134
i386: 0.112
KVM: 0.111
register: 0.085
boot: 0.082
TCG: 0.072
kernel: 0.063
VMM: 0.055
risc-v: 0.051
arm: 0.048
vnc: 0.043
files: 0.036

Slow UDP performance with virtio device

I'm working on an app that is very sensitive to round-trip latency
between the guest and host, and qemu/kvm seems to be significantly
slower than it needs to be.

The attached program is a ping/pong over UDP.  Call it with a single
argument to start a listener/echo server on that port.  With three
arguments it becomes a counted "pinger" that will exit after a
specified number of round trips for performance measurements.  For
example:

  $ gcc -o udp-pong udp-pong.c
  $ ./udp-pong 12345 &                       # start a listener on port 12345
  $ time ./udp-pong 127.0.0.1 12345 1000000  # time a million round trips

When run on the loopback device on a single machine (true on the host
or within a guest), I get about 100k/s.

When run across a port forward using "user" networking on qemu (or
kvm, the performance is the same) and the default rtl8139 driver (both
the host and guest are Ubuntu Lucid), I get about 10k/s.  This seems
very slow, but perhaps unavoidably so?

When run in the same configuration using the "virtio" driver, I get
only 2k/s.  This is almost certainly a bug in the virtio driver, given
that it's a paravirtualized device that is 5x slower than the "slow"
hardware emulation.

I get no meaningful change in performance between kvm/qemu.



Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU? Have you already tried vhost?

[Expired for QEMU because there has been no activity for 60 days.]