[Click] Userlevel performance issues

[Robert Ross]

That's an interesting idea.  I didn't know this element existed.  How
"experimental" is this element?  Also, when the documentation says 

"The FromUserDevice element expects that complete IP packets are written
into the device."

Does that mean it is expecting packets without an Ethernet header?


Robert Ross
DSCI Inc.
Office: 732.542.3113 x173
Home: 609.702.8114
Cell: 609.509.5139
Fax: 253.550.6198

-----Original Message-----
From: Roman Chertov [mailto:rchertov at purdue.edu] 
Sent: Friday, January 25, 2008 10:49 AM
To: Robert Ross
Cc: click at pdos.csail.mit.edu
Subject: Re: [Click] Userlevel performance issues

-----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-----