linux-um archives
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked@iki.fi>
To: Young Koh <young.koh@gmail.com>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: tun/tap network throughput problem
Date: Wed, 09 Mar 2005 11:25:38 +0200	[thread overview]
Message-ID: <87psy92mst.fsf@aka.i.naked.iki.fi> (raw)
In-Reply-To: <3524bf1f05030810517057e99d@mail.gmail.com> (Young Koh's message of "Tue, 8 Mar 2005 13:51:19 -0500")

Young Koh wrote:
>> In general, there's nothing to limit how many packets get queued to
>> the interface queue - if something sends a million packets, that is
>> how many packets are queued to the interface. However, for TCP,
>> there
>
> interesting. then, the UDP sending rate should be solely determined
> by system performance regardless of what kind of the network
> interface used, cause the rate will be determined by how fast the
> application enqueues packets to the device queue, which is an
> internal data structure in the kernel, right? when i measured UDP
> sending rate in the host machine, it was about 650Mbits/s. that
> means the throughput of data transfer from an application to the
> kernel internal structure is only 650Mbits/s? but, when i measured
> UDP sending rate with loopback device (sending packets to
> 127.0.0.1), it was about 5,000Mbits/s, which is a lot faster. should
> they, i mean, the sending rates for eth0 and lo, be the same? (maybe
> lo uses special queuing mechanism?)

Almost, but not quite. When packets are queued to the lo interface,
they are handled immediately, synchronously even. When packets are
queued to the eth0 interface, they get queued and the hardware
interrupts trigger their processing. This means that the userland
process is constantly being interrupted by the hardware sending
packets, where as in the lo case it can just fire away as it wants.

However, the speed difference seems too large to be simply caused by
that - so I am wondering a bit about the test tool, if it might manage
to do something special. Perhaps there is a way to see if the queue is
full from an UDP socket somehow, perhaps select does not return write
availability or something. Or perhaps it simply asks how much data is
in buffers - but I thought that only worked for receiving and TCP. I
would need to look into this a bit further.

-- Naked


-------------------------------------------------------
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-09  9:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 20:56 [uml-devel] tun/tap network throughput problem Young Koh
2005-03-08 11:27 ` [uml-devel] " 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 [this message]
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=87psy92mst.fsf@aka.i.naked.iki.fi \
    --to=naked@iki.fi \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=young.koh@gmail.com \
    /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