On Wed, Oct 19, 2011 at 6:33 PM, Jesse Gross <[email protected]> wrote:
> On Wed, Oct 19, 2011 at 5:28 PM, Ethan Jackson <[email protected]> wrote: > >> Implement ovs-vlan-test server logic so that it would restart iperf TCP > >> server every-time iperf-server exited because of this bug, > >> For TCP (or maybe also for UDP) use a different tool (e.g. nttcp, > netperf > >> ...). I suppose output from other tools would be a little bit tougher to > >> parse than for iperf, > >> Limit ovs-vlan-test server lifetime to a single testing session, so that > >> user manually has to restart ovs-vlan-test server if he wants to do > multiple > >> tests in a row, > >> Implement all iperf logic inside the ovs-vlan-test python script (would > >> python be good enough candidate for this performance wise?); > >> > >> Will try to come up with something soon. Anyway as a best long term > solution > >> I see #4, because then we would not have dependency on netper/iperf > >> STDOUT/STDERR format. Although that would be a little bit more time > >> consuming... > > > > Someone else may disagree, but I think #1 is the best choice. We are > > definitely going to want to run some sort of tcp stream test. I think > > iperf is going to be a lot better at implementing this sort of test > > than python code (especially on 10 gig links). Since we are going to > > need to run iperf anyway for the tcp stream test, we may as well do it > > for everything. However, Jesse knows the most about the specific > > problems we are targeting, so I would defer to him on this issue. > > iperf/netperf are actually a lot simpler than you probably think > (think loop around a call to write()...) so I'm not sure that the > language actually makes all that much of a difference unless Python > tries to something overly clever with I/O. I doubt that it does. > I actually did quick investigation for this. With Python (blocking sockets) I was able to push 6 Gbps of TCP traffic within localhost boundaries while with Iperf I was able to push 27Gbps (Xeon X3430) Not sure how much numbers would change if I would do this from event-loop and send traffic to a different host. Hard part would be UDP flow control that would require timer based approach. > That said, I'm not all that eager to reimplement all of iperf, since > we'd also have to create a control channel, etc. > I think that we can potentially embed all the Control Channel information in the first few bytes of the data channel (e.g. specify direction; and in case of UDP specify Target Bandwidth and datagram sizes). > > By the way, does the patch actually run bidirectional tests right now? > (I don't see it in a quick scan of the patch.) If not, it's > definitely important for all the test types. > Currently It does UDP bidirectional tests (Iperf is started with -d flag)
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
