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