Re: UDP - Iperf Loss ??
Hello Marc.
thank your for your prompt reply.
let me answer in between...
Marc Herbert wrote:
> On Thu, 29 Jul 2004, Marcelo Maraboli wrote:
>
>
>>Iperf:
>>PC1: iperf -c IP-PC2 -u -w 200k -l 12 -n 1785708 -b 100m
>> (which would lead to 148809 frames/s at 100mbps)
>>PC2: iperf -s -u -w 200k
>>
>>I know that 100m at UDP is different than 100m at Ethernet,
>>but I also tested at 90m.
>
>
> Headers in this case are 42 bytes long (just tested on loopback). So
> with -l 12, packets are 54 bytes long, so you can get at most...
> 22Mb/s. Quite different from 100M (or event 90M) indeed.
I do not agree (but maybe I´m wrong ;):
Ethernet header: 6+6+2 = 14 bytes
IP header: 20 bytes
udp header: 8 bytes
UDP data-payload: 12 bytes
Ethernet padding: 6 bytes
CRC FCS: 4 bytes
----
TOTAL Ethernet packet length: 64 bytes
,which is the minimum Ethernet packet length.
Your 42 header bytes only include: 14 + 20 + 8 = 42
>>STRANGE:
>>I check the frame counter on the switch, and the receiving
>>port does receive 148792 frames from PC1. The switch
>>outputs (on PC2 port) the amount of 148793 frames. (which
>>is saying that the switch is non-blocking or did not lose
>>any frames), but Iperf reports the following in PC2:
>>
>>time transfer bw jitter loss/total
>>0.0-2.3s 474 Kbytes 1.71Mbps 0.047ms 108341/148809 (73%)
>
>
> This is confusing: is the "148809" a rate (frames/s) or just a
> volume (frames) ?
It is not a rate, only total amount of packets that SHOULD be
received...
>
>
>
>>- This tells me that PC2 did not receive the 148809 frames ??
>
>
> Right, it only received 73% of them.
>
right!
>
>
>>- then how did it know there were 148809 frames sent to him ??
>
>
> iperf has its own (and convenient) protocol on top of UDP. Sequence
> numbers, ACKnowledgements, whatever...
>
that explains the few extra packets... ;)
>
>
>>- WHY did Iperf take 2.3s to send 148809 packets if I told
>>it to do it at 100mbps ?? (Dlink could not handle it?)
>
>
> Maybe because you can get only 22Mb/s because of protocols
> headers/overheads ? And there also maybe some queueing here and
> there...
>
Queueing in PC1-output, switch-input, switch-output and PC2-input.
The strange thing is that LOSS is only registered at PC2, because
Switch counters do not show any loss (error counters, drop counters).
Is this a Iperf flaw or a Operating System not tunned. ?
> Could you give more details about your computations and expectations ?
> (sorry, I am too lazy to re-do them by myself :-)
>
I am using Iperf to test switches at the maximum Ethernet
spec at various packet lenghts, as stated in RFC 2544.
My problem/goal is:
how can I use Iperf to generate 148809 Ethernet packets/s
of a 64 bytes length at 100Mbps ??? (to test the switch)
also meaning: it should take 1 second (if the NIC allows it),
and 1 second to receive it (if the switch and Pc2-NIC allows it).
thank you,
--
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/