[Click] Userlevel performance issues

Robert Ross rross at dsci.com
Fri Jan 25 10:37:46 EST 2008


We've been attempting to use userlevel Click here to perform some
traffic loading and analysis of specific network conditions and
behaviors.  The key important elements used are:

*	
	FromDump() for injecting packets
*	
	Socket() for injecting packets
*	
	FromHost() for injecting packets
*	
	To Device for sending packets
*	
	LinkUnqueue for link emulation

We also have the obvious need for queues and several other elements
which are not as critical to this discussion.  The problem came up when
we started examining element handler values duing experimentation:

*	We first found that when UserLevel Click started pulling from a
PCAP file, the performance of the ToDevice() appeared to drop sharply.
What I mean by this is that the ToDevice() pull handler reported values
in the range of 200 packets/second once the PCAP file started reading.
This resulted in the outbound queue just prior to the ToDevice() filling
up and eventually overflowing because the packet rate in the PCAP file
is far more than 200 packets/second.
*	We then tried using a Socket element to inject the packets
remotely rather than using the FromDump element.  We found that, for
some reason, the LinkUnqueue element appears to affect the Socket's
ability to pull packets quickly on the server side of the socket
connection.  If the LinkUnqueue element has a high enough bandwidth
parameter, then the socket itself has no problem keeping up with the
injected load and the traffic profile looks as expected.  This is also
true if you remove the LinkUnqueue element completely.  However, with
the LinkUnqueue element specified as "512Kbps" the upstream Socket
appears to slow itself down and only except packets from the client at a
fraction of what it is obviously capable.
*	We then tried using TCPReplay to inject the packets into the
Click configuration FromHost.  The behavior here was exactly the same as
the Socket element.  TCPReplay was only able to inject packets into the
fake device at a fraction of what should be possible (around 200
packets/second), the problem having some unknown relationship to the
LinkUnqueue element.  If LinkUnqueue is removed, TCPReplay packets are
pumped at the desired rate.

So, having tried (and failed) multiple ways to inject traffic at a high
speed, I have two ultimate questions:

1.	Why does reading from a PCAP file cause a drastic performance
hit on ToDevice pull processing?  How can this be resolved?  FromDump
doesn't work at kernellevel and multi-threading doesn't work at
userlevel.
2.	Why does the LinkUnqueue element impact behavior of the upstream
Socket and FromHost elements?  Is there any way to stop this from
happening and let the Socket and/or FromHost run as fast as possible?

 
Thanks,
Robert A. Ross
DSCI Inc.
609-509-5139


More information about the click mailing list