public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "SourceForge.net" <noreply@sourceforge.net>
To: noreply@sourceforge.net
Subject: [ kvm-Bugs-2005957 ] TAP networking stalls on large file transfers
Date: Sun, 29 Jun 2008 16:09:52 +0000	[thread overview]
Message-ID: <E1KCzTM-0004fM-LM@665xhf1.ch3.sourceforge.com> (raw)

Bugs item #2005957, was opened at 2008-06-29 19:12
Message generated for change (Comment added) made by andyz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2005957&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew Zabolotny (andyz)
Assigned to: Nobody/Anonymous (nobody)
Summary: TAP networking stalls on large file transfers

Initial Comment:
System: Fedora 9
KVM version: tried 65 and 70, both exhibit the same behaviour

When using TAP networking if I copy a large file from host to guest OS, I get extremely low performance (under 1 megabyte/s) and sometimes file transfer stalls. If I run tcpdump in guest OS (even with a bogus filter - e.g. tcpdump -nn -i eth0 host 1.2.3.4) the stalled connection suddenly come alive. If I run repeatedly tcpdump/press Ctrl+C and so on, the file transfer visually goes much faster.

I found a old thread about the same bug in QEMU: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290569

The patch proposed there was applied in QEMU 0.7.3, but when I looked into QEMU 0.9.1 sources - it is not there, so it seems it was removed for some reason. However, if I run the same virtual machine with QEMU, I get stable performance with about 8-9 megabytes per second flowing both ways (from host to guest and from guest to host).

I tried to apply the patch on KVM 70, but it does not make any difference :-(

The guest OS is Ubuntu 8.04 but I guess that does not matter.

I will be glad to cooperate to find/fix the bug but for now I'm out of ideas :-(


----------------------------------------------------------------------

>Comment By: Andrew Zabolotny (andyz)
Date: 2008-06-29 20:09

Message:
Logged In: YES 
user_id=1815
Originator: YES

Update: I was advised on irc to try e1000 network card emulation instead,
and with it I get very good results - 32 megabytes per second and more. So
the bug occurs only with rtl8139 emulation, perhaps because of bandwidth
limitation (packets aren't read quick enough from the TAP handle)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2005957&group_id=180599

             reply	other threads:[~2008-06-29 16:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-29 16:09 SourceForge.net [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-08-30  6:57 [ kvm-Bugs-2005957 ] TAP networking stalls on large file transfers SourceForge.net
2010-08-27 21:16 SourceForge.net
2010-08-19 10:22 SourceForge.net
2008-08-09  8:54 SourceForge.net
2008-08-09  6:04 SourceForge.net
2008-08-09  5:51 SourceForge.net
2008-06-29 15:12 SourceForge.net

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1KCzTM-0004fM-LM@665xhf1.ch3.sourceforge.com \
    --to=noreply@sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox