Re: UDP - Iperf Loss ??
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.
> 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) ?
> - This tells me that PC2 did not receive the 148809 frames ??
Right, it only received 73% of them.
> - 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...
> - 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...
Could you give more details about your computations and expectations ?
(sorry, I am too lazy to re-do them by myself :-)