The first set of tests were used to both charicterize the generation cluster, as well as charicterise the bridging capacities of the DUTS. Our initial testing matrix is a 3 x 3 x 3 cube. Three DUTs, the patch_loop, the intel_dual and the realtek_dual DUTS, the three types of traffic generation, and three configurations.

The initial three configurations are bridge, passthrough and snort_inline.null. By comparing the resulting speeds of the different configurations a basic understanding of the performance space can be found. By looking the differing pktrates between the patch_loop and the DUTS we can aproximately determine how much capacity remains in the traffic generation above the DUT.

As can be seen in upper left graph Traffic type vs maximal pkts/sec. The basic.pkthoze_size traffic profile results in aproximately the same pkts / sec for both the patch_loop and the intel_dual. From this we can deduce that this traffic profile is probibly at or near capacity when run accross the DUT. As can be seen by the basic.wget_mtuslide traffic profile, both the patch_loop and the intel_dual can go much faster. So by using differing traffic generation styles we can drive differnet speeds out of the DUTS. By combining the results we are able to continue analysis on all profiles when one of the traffic genorators lets us down.

Looking at the center graphs of the various confgurations we can start to see the good stuff. By comparing the speeds of the bridge and passthrough configurations we can see that this is where the majority of the pkts/sec performance is going, yet only about 1/3 of the mbits/sec perfromance.

The difference between bridge and passthrough is the difference between libipq and forcing packets to go into userland. Because the libipq interface can only deal with one packet at a time this is a large constraint on the maximal number of packets, but not nessisarily a large constraint on bandwidth.

By comparing the difference between passthrough and snort_inline.null, you can get an idea of how much overhead snort_inline has for dealing with packets. The passthrough does basicly nothing with the packet, whereas snort needs to somewhat more than simply close it's elctronic eyes. Snort uses about %15-25 of it's avalible performance on administrative task and plumbing the packets around the system.

Metric	Device Under Test	Configuration	Traffic type
Packets / Sec outofdut
Mbits / Sec outofdut

It can also be seen that the two snort_inline DUTS are showing there differences. In the snort_inline.null configuration the intel based device can do 125pkts/sec or about 400 Mbits a second in bridging mode, where as the realtek device is down around 60K pkts/sec or almost 300 Mbits/sec. By the time the extra layers of software are added, the resulting maximal speed we see out of snort is between 15-30 Kpkts /sec and in the 160-190 Mbits range.