All of lore.kernel.org
 help / color / mirror / Atom feed
From: Young Koh <young.koh@gmail.com>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] tun/tap network throughput problem
Date: Mon, 7 Mar 2005 15:56:39 -0500	[thread overview]
Message-ID: <3524bf1f05030712562d547e1c@mail.gmail.com> (raw)

Hi,

i was running an expriment to measure network throughput of UML.
physical machine A and B are connected with gigabit network. and UML
runs on machine A. i'm sending bulk UDP packets from UML to machine B
using ttcp network throughput benchmark program.
i'm using 2.4.26 for both UML and host. (skas + sysemu patched)

i modified UML kernel code to get high performance a little bit, and i
got some gain with TCP and UDP throughput. but the problem arises when
i send large UDP packets with high sending rate. when i send 16K-sized
UDP packets with rate of 500Mbits/s, receiving rate at machine B was
about the same (~500Mbits/s), i mean, no problem. but when i send
16K-sized UDP packets with higher rate of more than 700Mbits/s, the
receiving rate drops to 150Mbits/s. (MTU = 1500)

i'm using tun/tap + bridge. so, i checked tap0 and eth0 device status,
but no packet drop reported (using ifconfig). i also checked the
number of packets received and sent. tap0 at host side received around
60007 packets, and eth0 at machine A sends 505536 packets during that
experiment. eth0 at machine B receives 505533 packets. so, it looks
like between tap0 and eth0, packets are being dropped somehow. (the
reason of dropping rapidly from 700 to 150 is the entire UDP packet
will be lost even if one of the fragmented packets is lost, i think)

i used tcpdump to check any trouble with UDP checksum because i saw
some posting about bug of bad UDP checksum when a UDP packet is
fragmented, but no checksum failure reported. (and it works well with
the lower sending rate)

i found other postings discussing queues of tun/tap devices when
packets are coming to UML kernel and between two UML machines. but i
couldn't find posting about packets from UML to other machine, even
though they are all related, it looks.

anybody has any idea where packets are being dropped and how i can solve it?

thank you,


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

             reply	other threads:[~2005-03-07 20:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 20:56 Young Koh [this message]
2005-03-08 11:27 ` [uml-devel] Re: tun/tap network throughput problem Nuutti Kotivuori
2005-03-08 16:42   ` Young Koh
2005-03-08 17:46     ` Nuutti Kotivuori
2005-03-08 18:51       ` Young Koh
2005-03-09  9:25         ` Nuutti Kotivuori
2005-03-09 11:48           ` Nuutti Kotivuori
2005-03-10 17:39       ` Rob Landley
2005-03-09 19:29 ` [uml-devel] " Blaisorblade
2005-03-09 21:46   ` Young Koh

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=3524bf1f05030712562d547e1c@mail.gmail.com \
    --to=young.koh@gmail.com \
    --cc=user-mode-linux-devel@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.