wire rate vs UDP throughput
On Fri, 30 Jul 2004, Marcelo Maraboli wrote:
> > 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
You are probably right; I just made a quick test on the loopback
interface to get an idea.
The argument still is: with small payloads, the proportion of headers
is huge, and the throughput at the UDP level is very far from the wire
rate.
> 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. ?
This is interesting. I can see two explanations:
- The switch output counter is flawed: it counts packet before they
actually get out, and the output has less performance than the
input. OK, this is unlikely.
- The receive interface is not able to process high packet rates (even
if it can process 100Mb/s but with big packets). The operating
system is not aware of this. Some drivers are able to report such drops.
Please report your later findings.
> 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)
The iperf interface allows you to specify the throughput at the
UDP level, not the throughput on the wire. You have to compute the
former from the latter (just like we did above). I think some guy
asked for this feature some months ago (check the archive). This is
just "too hard" to implement since iperf has no knowledge about lower
layers. A common case (IP, Ethernet) could be implemented, but this
would be quite dirty IMHO.
On the other hand, if you just want "full wire speed", you just have
to configure your sending system to avoid drops on the sender (on
linux, you just have to check that -w SND_BUF << ifconfig txqueuelen),
and then you just ask "full speed" to iperf, that is: iperf -b 2G.
Also try to keep queues small to avoid jitter. For instance set both
SND_BUF and txqueuelen at relatively small values on linux.
Cheers,
Marc.