Re: UDP Connection tuning questions regarding the -b and -l options
Hello Jim
Jim Mozley wrote:
> 1. Using the -b option
>
> I have the testing servers on 100 Mb links. As I increase the -b option
> to near this figure I see increased datagram loss. I assume this is due
> to the addition of IP packet and ethernet frame information causing
> datagrams to be split into packets. Can someone confirm/clarify my
> understanding?
>
> iperf -u -c 172.18.1.1 -l 1470B -b 95m -t 5
> 0.0- 5.0 sec 57.0 MBytes 95.5 Mbits/sec 0.032 ms 21/40652 (0.052%)
>
> iperf -u -c 172.18.1.1 -l 1470B -b 98m -t 5
> 0.0- 5.0 sec 57.4 MBytes 95.4 Mbits/sec 0.029 ms 1065/42019 (2.5%)
>
> iperf -u -c 172.18.1.1 -l 1470B -b 100m -t 5
> 0.0- 5.0 sec 57.4 MBytes 95.4 Mbits/sec 0.053 ms 1783/42737 (4.2%)
for UDP, the -l parameter is 1470 bytes by default (no need
to set it). The UDP datagrams are NOT split into multiple
Ethernet Packets since they fit in the 1518 Max. Ethernet
packet length.
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.. ;)
>
> 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...
>
> If I lower the -l option from the default of 1470B I see an increase
> data loss the lower I go.
>
> iperf -u -c 172.18.1.1 -l 1470B -b 90m -t 5
> 0.0- 5.0 sec 53.9 MBytes 90.5 Mbits/sec 0.017 ms 0/38463 (0%)
>
> iperf -u -c 172.18.1.1 -l 1000B -b 90m -t 5
> 0.0- 5.0 sec 54.2 MBytes 90.9 Mbits/sec 0.046 ms 0/56820 (0%)
>
> iperf -u -c 172.18.1.1 -l 100B -b 90m -t 5
> 0.0- 5.0 sec 35.1 MBytes 58.8 Mbits/sec 0.025 ms 230978/599009 (39%)
no need to use "B" for byte, it assumes it.
the increasing loss rate is due to the fact that something
in between cannot allocate that amount of packets (queues,etc)
at that rate... you must test it separately...
>
> If I remove the -b option I see no datagram loss, but a considerably
> slower bandwidth.
>
> iperf -u -c 172.18.1.1 -l 100B -t 5
> 0.0- 5.0 sec 641 KBytes 1.05 Mbits/sec 0.025 ms 0/ 6563 (0%)
yes, the default for "-b" is 1 Mbps
>
> 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 :-(. 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).
>
> If this is the case I suppose I need to test the servers back to back
> and then with the switches in between to see the difference the network
> devices. As an alternative I can get the NIC cards/switches to report
> packet loss via something like SNMP or interfaces counters available
> from the command line. Is this a typical approach?
yes, test every part first, and then the network....
divide to conquer
regards,
>
> Thanks,
>
> Jim Mozley
>
>
--
Marcelo Maraboli Rosselott
Jefe Area de Redes (Network & UNIX Systems Administrator)
Ingeniero Civil Electronico (Electronic Engineer)
Direccion Central de Servicios Computacionales (DCSC)
Universidad Tecnica Federico Santa Maria, Chile.
phone: +56 32 654237
mailto:marcelo.maraboli --at-- dcsc.utfsm.cl http://elqui.dcsc.utfsm.cl/