Beyers, I just tested with the CAPTURE PCAP and it works great. I also applied the patch that you posted. I do agree that CAPTURE PCAP method should be a default option. I wonder if anybody has any objections to changing the default CAPTURE method to PCAP.
Roman On Sat, 30 Oct 2010 02:02:55 +0200 Beyers Cronje <[email protected]> wrote > Hi Roman, > > I've done a couple of tests. Here are my findings: > > 1) Using FromDevice with default Linux capture method: > > [r...@slacker click]# userlevel/click conf/r.click -h ctr1.count h > ctr2.count > ctr1.count: 100000 > ctr2.count: 12980 > > 2) Increasing /proc/sys/net/core/rmem_max > and /proc/sys/net/core/rmem_default to 1048568 yields better results, but > still very poor: > > [r...@slacker click]# userlevel/click conf/r.click -h ctr1.count -h > ctr2.count > ctr1.count: 100000 > ctr2.count: 58263 > > 3) And finally, using PCAP capture method, i.e. FromDevice(eth1, SNIFFER > false, PROMISC true, CAPTURE PCAP) > > [r...@slacker click]# userlevel/click conf/r.click -h ctr1.count -h > ctr2.count > ctr1.count: 100000 > ctr2.count: 100000 > > > My conclusion is that the default FromDevice capture method utilizing Linux > packet socket RX processing is pretty crap. I'm sure this is not because of > Click but rather how the kernel handles it. On the other hand the PCAP > capture method seems to perform really well. Maybe we should look at setting > the default method to PCAP for Linux as well? > > One last thing, the patch I just mailed to the list fixes an issue where > "SNIFFER false" was not honored and you ended up in sniffer mode, which > might affect performance. > > Beyers > > > > On Fri, Oct 29, 2010 at 1:37 AM, Roman Chertov <[email protected]> wrote: > > > On Thu, 28 Oct 2010 13:58:50 -0700 Cliff Frey <[email protected]> wrote > > > > > I don't have a setup that I can easily/quickly use to test. All the > > same, > > > I'm curious what the interface statistics do during this time on both of > > the > > > interfaces (i.e. any errors? how many packets transmitted/received) > > > > [local]# click test2.click -h ctr1.count -h ctr2.count -h fd.count -h > > fd.kernel_drops > > ctr1.count: > > 100000 > > > > ctr2.count: > > 4503 > > > > fd.count: > > 0 > > > > fd.kernel_drops: > > ?? > > > > ?? means that the number of kernel drops is unknown. > > > > [local]# ethtool -S eth2 > > NIC statistics: > > rx_packets: 9 > > tx_packets: 100011 > > rx_bytes: 2749 > > tx_bytes: 150401691 > > > > [local]# ethtool -S eth3 > > NIC statistics: > > rx_packets: 100004 > > tx_packets: 17 > > rx_bytes: 150400641 > > tx_bytes: 3429 > > > > According to ethtool, all of the 100000 packets were sent and received w/o > > issues (the extra packets are due to IPv6 when the interfaces came on). > > > > So it looks like that problem is somewhere between Linux and Click getting > > the > > packets to ToDevice. I am curious what results Bejers will get. > > > > Roman > > > > > > > > Also, I'm curious what was going on inside of ToDevice and FromDevice. > > The > > > linuxmodule version of these elements have a bunch of counters (visible > > > through the "calls" handler), it would be cool if the userlevel versions > > had > > > these things too (i.e. run_select_count, packets for both, write_errors, > > > empty_pulls for ToDevice, recvfrom_errors, recvfrom_eagains for > > fromdevice) > > > > > > I doubt it, but you also might get different behavior if you add a Queue > > > between the ratedsource and the todevice. > > > > > > Cliff > > > > > > On Thu, Oct 28, 2010 at 10:55 AM, Roman Chertov <[email protected] > > >wrote: > > > > > > > Hello, > > > > > > > > I was curious if anybody could try this test for me using userlevel > > click. > > > > I am > > > > running CentOS 5.5 2.6.18-194.17.1.el5, and I have two network cards > > > > connected > > > > with a single cable. If I run the script below using userlevel click, > > > > FromDevice(eth3) will receive very few packets and the majority would > > end > > > > up > > > > dropped on input. > > > > > > > > src :: RatedSource(\<00>, LENGTH 1458, RATE 8000, LIMIT 100000) > > > > -> UDPIPEncap(10.0.1.1, 6667, 20.0.0.2, 6667) > > > > -> EtherEncap(0x0800, 00:30:48:F9:EA:7B, 00:17:cb:0d:f8:db) > > > > -> ctr1 :: AverageCounter > > > > -> ToDevice(eth2); > > > > > > > > > > > > fd :: FromDevice(eth3, SNIFFER false, PROMISC true) > > > > -> ctr2 :: AverageCounter > > > > -> Discard; > > > > > > > > This script just requires ethX names to be changed; otherwise, it can > > be > > > > run as > > > > is. > > > > > > > > [root]# click test2.click -h ctr1.count -h ctr2.count > > > > ctr1.count: > > > > 100000 > > > > > > > > ctr2.count: > > > > 4482 > > > > > > > > Roman > > > > > > > > > > > > _______________________________________________ > > > > click mailing list > > > > [email protected] > > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > > > > > > > _______________________________________________ > > click mailing list > > [email protected] > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
