Lakshminarayanan Subramanian: Re: Questions on Click

Eddie Kohler eddietwo at amsterdam.lcs.mit.edu
Wed Dec 13 14:18:52 EST 2000


------- Forwarded Message

Replied: Wed, 13 Dec 2000 14:17:59 -0500
Replied: "Lakshminarayanan Subramanian <lakme at CS.Berkeley.EDU> "
Received: from relay.EECS.Berkeley.EDU (relay.EECS.Berkeley.EDU [169.229.34.228])
	by amsterdam.lcs.mit.edu (8.10.1/8.10.1) with ESMTP id eBDJA9217333
	for <eddietwo at amsterdam.lcs.mit.edu>; Wed, 13 Dec 2000 14:10:09 -0500 (EST)
Received: from quito.CS.Berkeley.EDU (quito.CS.Berkeley.EDU [128.32.46.233])
	by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA13518;
	Wed, 13 Dec 2000 11:10:07 -0800 (PST)
Received: from localhost (lakme at localhost)
	by quito.CS.Berkeley.EDU (8.9.1a/8.9.1) with ESMTP id LAA09406;
	Wed, 13 Dec 2000 11:10:06 -0800 (PST)
Date: Wed, 13 Dec 2000 11:10:06 -0800 (PST)
From: Lakshminarayanan Subramanian <lakme at CS.Berkeley.EDU>
To: Eddie Kohler <eddietwo at amsterdam.lcs.mit.edu>
cc: <george at secundus.org>
Subject: Re: Questions on Click 
In-Reply-To: <200012131818.eBDIIG231544 at amsterdam.lcs.mit.edu>
Message-ID: <Pine.SOL.4.30.0012131042030.9400-100000 at quito.CS.Berkeley.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Eddie,
	We could not solve the problem with the kernel mode. Thanks for
your feedback on the UDP header. After running TCP dump we found
out that the ToDevice routine was able to send the packet but the packet
had some ID problems which I mentioned to you earlier. We will try to make
the change that you suggested and see what happens in kernel mode.

	Presently we are making our measurements on User level with
interrupts and no polling. I did read thru your TOCS paper and saw the
huge difference in performance between polling and no polling.

>From our measurements we found out that the reduction in maximum throughput
caused by our monitoring software when added to Click was between 5% and
7% at saturation(peak load) and 0% elsewhere. We are using Click to
quantify this percentage overhead. Though the actual throughput numbers
may differ, do you think the percentage will differ for the kernel mode
and the user mode? We are doing some additional packet processing and
monitoring in our software.

	We are making these measurements for our SIGCOMM paper and would
like to get your feedback on the correctness of our approach in using
Click. We also saw a relatively large drop in peak throughput when we
downloaded a large routing table of BBNplanet into Click and disabled the
cache.

Our Setup:
- ----------

	Presently from our measurements we observe a peak throughput of
32Mbps using basic Click and around 30.4Mbps using Click+our Monitoring
software. At higher loads the throughput starts dropping.
	Our setup is over a collection of machines connected using 100Mbps
links to a Bay Networks router which has a capacity to process packets
at 1.6Gbps.
	The Click router is run over a 650Mhz P-III machine and it has a
3c59x ethernet card with a 32-bit bus.  So we could not perform the
optimizations you folks performed using the DECTulip card.
	The max traffic I could anyway send between two machines in my
cluster was around 38-40Mbps independent of Click. Sysadmins at Berkeley
told me that this throughput was close to the maximum value I could get
out of this system.
	All these measurements are with the large routing table.
So do you think our measurements in user level could be reported in the
paper with some confidence? Our main interest is in charecterizing the
percentage overhead and not the actual throughput.

	We will try the kernel mode and let you know of our progress.

Thanks a lot for your help.

- --lakshmi

On Wed, 13 Dec 2000, Eddie Kohler wrote:

> Hi Lakshmi,
>
> The difference between Click with and without polling is pretty huge -- a
> factor of 5 or more. You can see this in graphs from our TOCS paper
> (available at pdos.lcs.mit.edu/click ). The Click interrupting performance
> is about the same as Linux's performance with interrupts.
>
> > 1. The FromDevice and ToDevice routines do not seem to sending packets all
> > the time. We started a flow from a traffic generator of very low bandwidth
> > to the Click router and the traffic generator seems to have sent the
> > packet but the Click does not receive it in kernel mode. The fromdevice
> > routine does not seem to work. However we could receive the packet in
> > user mode. We are running Click on top of Linux 2.2.17
> > We are facing similar problems with ToDevice routine. it does not send
> > packets from Click.
>
> We don't use FromDevice very much any more, so it is possible that the code
> is not working properly. But it would surprise me. Could you send us the
> actual configurations yoiu used? Or have you worked on this problem since
> writing this email, pinned down the problem more, and that was the other
> email you sent?
>
> Thanks
> Eddie Kohler
> Click people
>


------- End of Forwarded Message




More information about the click mailing list