On Thu, Dec 29, 2005 at 12:29:55AM +0100, Aritz Bastida wrote: > So, after these all tests I'm thinking of using two injector machines > which will send to ksensor, in order to achieve an aggregated > throughput. By the way, if a switch is connected to all these > machines, there wouldn't be any collision, right? (Because the > communication is one way only, i think)
What do you mean by 'collision'? It should definitely be possible to connect two load generators and one sniffer box to the same switch so as to increase the traffic rate to the sniffer. > KSENSOR (receiver) > ------------------------------------------------------------------------- > Machine: Dual AMD Opteron 1800MHz > NIC: tg3 Broadcom BCM5704 > PCI-X: 100MHz : 64-bit That should be fast enough for fairly high packet rates (say, half a million packets per second.) > INJECTOR A > ------------------------------------------------------ > Pentium 4 2.80 GHz > NIC: e1000 Intel 82547GI > PCI: 33 MHz : 32-bit > > > INJECTOR B > ------------------------------------------------------ > Dual Pentium III 866Mhz > NIC: e1000 Intel 82540EM > PCI: 33 MHz : 32-bit 33MHz 32bit PCI is just slow (considering chipset latency) -- you're not going to get very high packet rates from it. Do these machines have faster PCI buses? If no, you can still try using pktgen with multiple NICs -- i.e. put two 32MHz 32bit NICs in one machine to try and overlap PCI activity a bit. > >From Jesse: > > Also, you'll get a big improvement from running a UP kernel with > > packetgen. > > Why? Pktgen threads can be bound to a specific processor. Probably locking overhead -- on an SMP box, there is still an amount of multiprocessor synchronisation that is done even if you only use one CPU, compared to a single-CPU kernel. > However, my problem was the contrary. The Pentium 4 (single processor) > couldnt send faster than the old Pentium 3 (two processors - but just > one used with pktgen). The Pentium 3 will probably send even faster if you run an UP kernel on it. > >From Robert: > > Also make sure HW_FLOW control from the receiver is not throttling > > the sender > > Well I'm not sure what hw_flow is. Not exactly sure what Robert means, but I think he means that you should disable PAUSE frames in your NICs. What might be happening if you have the generator and the sniffer connected with a cross-cable, that the sniffer will send a special kind of packet, a PAUSE packet, to the generator machine when it can't keep up with the load. You can turn PAUSE frames off with ethtool. > I mean, if the packets are arriving so fast that the network card has > to say "stop it" probably the kernel wont be able to capture them, right? Normal network traffic is elastic to a certain degree (meaning that the incoming traffic rate will get lower if you drop or delay packets), and in that case, PAUSE frames (should in theory) help to overcome temporary buffer shortages in the receiver. I'm told that this is the reason why the tg3 driver has PAUSE on by default. (If your traffic is inelastic (i.e. it will not back off under load), sending PAUSE frames is kind of pointless and it shouldn't really matter whether they are on or off.) > By the way, as I said, the receiving machine has to analyze all the > traffic in a Gigabit link (it works much like an Intrusion Detection > System). So the normal thing would be just to listen the link. So, for > that matter the nic is put in promiscuous mode. I don't know if that > has to do anything with flow control (may be it's turned off when the > card is in promiscous mode). No, different issue. > Anyway, forgetting for a moment about this specific test I'm trying to > do, should it be for my application (something like an IDS) the > HW_FLOW turned on or off? (I guess it's "off", since the capture would > be pasive). If you are capturing, PAUSE frames have no use -- if you lose packets, you lose packets. If the incoming load is 1 million packets per second and you can't keep up, you can't keep up. --L - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
