[Qemu-devel] [Bug 597351] Re: Slow UDP performance with virtio device

[Qemu-devel] [Bug 597351] Re: Slow UDP performance with virtio device

[Andy Ross]

** Attachment added: "udp-pong.c"
   http://launchpadlibrarian.net/50751155/udp-pong.c

-- 
Slow UDP performance with virtio device
https://bugs.launchpad.net/bugs/597351
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
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.

[Qemu-devel] [Bug 597351] [NEW] Slow UDP performance with virtio device

[Andy Ross]

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
Slow UDP performance with virtio device
https://bugs.launchpad.net/bugs/597351
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
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.

[Qemu-devel] [Bug 597351] Re: Slow UDP performance with virtio device

[Thomas Huth]

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

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/597351

Title:
  Slow UDP performance with virtio device

Status in QEMU:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/597351/+subscriptions

[Qemu-devel] [Bug 597351] Re: Slow UDP performance with virtio device

[Launchpad Bug Tracker]

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

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/597351

Title:
  Slow UDP performance with virtio device

Status in QEMU:
  Expired

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/597351/+subscriptions