Minlan is at Princeton so I'm not exactly sure the experimental setup.
I doubt it is openvswitch.
The hardware switch issue is a tricky one. Some switches appear to have
hardware limitations. However, others it seems to be a simple
configuration issue. Justin was able to get tens of thousands of
packets/s off a broadcom chip with an LB4G once he turned off rate
limiting to the mcpu.
.m
Thanks for the data Martin.
Can you describe the switches used for this? Were they openvswitch?
I assume the switches were running on a different machine than the nox
instance, to avoid CPU contention?
I've run similar numbers with the cbench utility that ships with
oflops: it simply emulates k switches and for each switch, tests the
number of packet_in/flow_mod responses a controller can produce, per
second. AFAICT, these should be basically the same numbers.
Also, as a data point, the hardware switches we've tested are no where
near capable of producing that number of flow setups per second. They
generally support hundreds of flow setups per second, due to their
limited CPU.
- Rob
.
On Sat, Jan 23, 2010 at 11:30 PM, Martin Casado <[email protected]> wrote:
Minlan recently did some performance analysis of Nox and has kindly agreed
to let me post the results to the mailing list. For those who might be
interested:
#switch flows/sec (peak rate)
1 18K
2 29K
3 39K
4 59K
5 45K
6 50K
This is roughly consistent with the numbers I've seen when doing similar
tests. It is important to note that in general, multiple switches are
required to saturate Nox.
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
