Click performance benchmark results #1

[Joe Elliott]

Hello Brecht,
	The config I gave in the last email was a typo, I was using
Poll and Counter and not Print.

Here are the latest results of my benchmarks with Tulip and EEPro NIC's

# Date Mar 1 02
#
# Fresh RH7.1 OS load - minimal services.
# Click 1.2.3 with kernel 2.2.19 (eepro patch from 2.2.18 - not in Click 2.2.19 patch!)
2 Nics:
eth1 - Tulip
eth2 - Intel

S/W traffic generator sending 1M pkts at 50Mb/s with 96Byte pings (~ 71K pps)
All tests use the same traffic source and config.

Click host - Dell Dimension 8100 1.4GHZ/256MB

Test #1 - Just counting packets with kernel module.
-------
PollDevice(eth1,1) -> Counter -> Discard        - 715368 (~28% loss)
FromDevice(eth1,1) -> Counter -> Discard        - 358281 (~64% loss)
PollDevice(eth2,1) -> Counter -> Discard        - 707318 (~29% loss)
FromDevice(eth2,1) -> Counter -> Discard        - would not work? - count=0
(same problem as below in test 3.4?)

Test #2 - Using pcap - no click code loaded.
-------
tcpdump -pi eth1 -w test1.bin - 259502 packets received (~74% loss)
tcpdump -pi eth2 -w test2.bin - 342921 packets received (~65% loss)

Test #3 - Copying traffic to user level socket with Poll and From methods.
-------
# TULIP Poll
FromLinux(joe0, 10.0.0.1/8) -> Idle;
PollDevice(eth1, 1) -> ToLinuxSniffers(joe0);
tcpdump -i joe0 -w testJoe.bin - 74752 packets received (~93% loss)

# TULIP From
FromLinux(joe0, 10.0.0.1/8) -> Idle;
FromDevice(eth1, 1) -> ToLinuxSniffers(joe0);
tcpdump -i joe0 -w testJoe.bin - 197672 packets received (~80% loss)

# Intel Poll
FromLinux(joe0, 10.0.0.1/8) -> Idle;
PollDevice(eth2, 1) -> ToLinuxSniffers(joe0);
tcpdump -pi joe0 -w test2.bin - 10116 packets received (~99% loss)

# Intel From
FromLinux(joe0, 10.0.0.1/8) -> Idle;
FromDevice(eth2) -> ToLinuxSniffers(joe0);
tcpdump -i joe0 -w testJoe.bin - 176512 packets received (~82% loss)
for this I have to put eth2 into promisc mode manually - 'ifconfig eth2 promisc'
or I get no traffic.

All traffic is going thro a Netgear 10/100 hub. clean 100Mbit traffic. No collisions seen.

Any ideas on how I can improve performance or test where the problem is?
I am willing to run tests if someone can send me sample configs. Am I
correct in assuming I should get all traffic with polling to wirespeed?
ie up to ~150K PPS per interface?

Look forward to any help! -- Joe.

-- 
                                          __o       _~o       __o
                                         `\<,      `\<,      `\<,
 ______________________________________(*)/_(*)__(*)/_(*)__(*)/_(*)________
 Im a 21st Century Digital Boy ... I aint got a life, but I got lotsa toys.
 *******************     Joe Elliott  joe at inetd.com    ********************
 Phone:(650)961-6631    Cell:(650)714-3932    Inetd.Com    http://inetd.com
 --------------------------------------------------------------------------

On Fri, 1 Mar 2002, Brecht Vermeulen wrote:

> Date: Fri, 01 Mar 2002 08:25:44 +0100
> From: Brecht Vermeulen <brecht.vermeulen at rug.ac.be>
> To: Joe Elliott <joe at inetd.com>
> Cc: click at amsterdam.lcs.mit.edu
> Subject: Re: Best Click Linux distribution?
>
>
> Hi Joe,
>
> >
> > If I use click module with polling interface on tulip and do the same 100K pkts
> > I get far less. I was hoping for a BIG improvement.
> >
> > # cat > /proc/click/config
> > FromLinux(joe0, 10.0.0.1/8) -> Idle;
> > FromDevice(eth1, 1) -> Print(ok) -> ToLinuxSniffers(joe0);
> >
>
> mmm, for polling you need to use PollDevice instead of FromDevice and I
> think the Print(ok) does also insert a big delay if you do this for each
> packet (logging to syslog).
>
> > # tcpdump -npi joe0 -w dump.bin
> > tcpdump: listening on joe0
> > 33045 packets received by filter (around 65% loss)
> >
> > Any ideas? How can I just count packets recieved by click ?
> >
>
> simply use counter, it will also calculate the rate for you.
>
> Just use e.g. PollDevice(eth1,1) -> Counter -> ToLinuxSniffers();
>
> We are also interested in your results, so if you could post something
> if you have interesting (faster :-) ) results. I have tried the same but
> only on a singleprocessor for now (multiprocessor would be done in a few
> weeks) and there I thought indeed the click-tcpdump was slower because
> click takes all processing power.
>
> regards,
> Brecht
>