Re: UDP Connection tuning questions regarding the -b and -l options
On Tue, 3 Aug 2004, Marcelo Maraboli wrote:
> Ethernet header: 14 bytes
> IP header: 20 bytes
> UDP header: 8 bytes
> UDP data: 1470 bytes (your -l option)
> Ethernet CRC FCS: 4 bytes
>
> TOTAL : 1516 bytes..... --> just one Ethernet Packet for that UDP size.
>
> The incresing rate loss is due to the fact (as Marc explianed it),
> that IPERF tries to send 100Mbps of UDP data in a 100Mbps Ethernet
> network....obviously impossible due to headers.. ;)
.. and I strongly suggest you don't ask iperf to send more data than
the wire capacity unless you really understand what you are doing and
want to study very tricky queueing issues in operating systems and
elsewhere.
> > 1. Using the -l option
> >
> > In the user guide I see in the example both the server and client have
> > the -l option for a test. Is this necessary on the server, or will it
> > accept any size (this seems to be the case from my investigation so
> > far)? I wanted to leave the server running without having to change its
> > parameters each time.
>
> yes, just put the server to "iperf -s -u" and use the
> CLient as you wish...
Right, but be careful, there is a caveat: if it is an UDP connection,
and if -l is smaller on the receiver (server) than on the sender
(client), then you will lose some data at each packet and the reported
throughput will be different on client and server. Check "man recv".
> > Can someone explain this? I have seen a previous post this month that I
> > think asks the same question but didn't follow the answer :-(.
Fortunately the archive is available online.
http://archive.ncsa.uiuc.edu/lists/iperf-users/
Even it there is no search engine, you can search it through google
like this:
http://www.google.com/search?q=site%3Aarchive.ncsa.uiuc.edu+headers+bandwidth
Please check it, you will find previous messages about this issue.
> > As I understand it I am stressing the server nics and switches
> > more by trying to achieve the same bandwidth throughput with many
> > more (and less optimal from the hardware's point of view) packets.
> > Hence more are dropped by the hardware (or OS).
Not really "the same throughput".
Since the -b option specify the throughput at the *UDP* level, when:
-b is constant
-l is variable
then the throughput on the wire is _variable_, because you need to
send _more_ packets (and thus more headers) for the same amount of
user (-b) data. For low -l values, the throughput on the wire can
even _exceed_ 100Mb/s, which is probably not what you want if you only
have a 100Mb/s interface.
Seen the other way round, if you want to keep the wire rate constant
while -l is variable, then you need an adjusted, variable -b. Sorry.