[Click] Userlevel performance issues

[Roman Chertov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross,

http://www.read.cs.ucla.edu/click/elements/fromuserdevice
You might want to look into FromUserDevice element.  It runs in kernel
level Click and then you can have a user level program just write raw
packets into the element via /dev/touserX.

Roman

Robert Ross wrote:
> 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
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmgTcT8ksiSCF2AYRApTxAKCFSvT4DiwCYhnFjZz/BIblWWCz0ACgh+4k
C2Vm2CPfc01IQJ8LGqPxjrM=
=Ldwl
-----END PGP SIGNATURE-----