After all I decided that best option actually would be to re-implement the iperf logic inside the ovs-vlan-test python script itself, because of following reasons:
1. flag "--tradeoff" (bidirectional, individual test) does not work for TCP: http://sourceforge.net/tracker/index.php?func=detail&aid=1949942&group_id=128336&atid=711371 2. iperf server process silently exits for TCP tests http://sourceforge.net/tracker/?func=detail&aid=1983829&group_id=128336&atid=711371 3. ovs-vlan-test parser will not depend on iperf's STDOUT or STDERR format (the format potentially might change between different iperf versions) 4. ovs-vlan-test will not have dependency on iperf or python-twisted packages anymore (just pure python standard library that has socket support) 5. most likely we would prefer if socket would belong to ovs-vlan-test script process instead of iperf, so that in future we could use setsockopt/getsockopt calls to get more control over TCP I already implemented TCP tests in pure python; UDP tests will be ready soon. Within localhost boundaries and non-blocking sockets in Python I was able to get close to 10 Gbps of traffic. Thanks, Ansis On Wed, Oct 19, 2011 at 8:45 PM, Jesse Gross <je...@nicira.com> wrote: > On Wed, Oct 19, 2011 at 6:55 PM, Ansis Atteka <aatt...@nicira.com> wrote: > > > > On Wed, Oct 19, 2011 at 6:33 PM, Jesse Gross <je...@nicira.com> wrote: > >> > >> On Wed, Oct 19, 2011 at 5:28 PM, Ethan Jackson <et...@nicira.com> > 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. > > OK, that's interesting. > > >> > >> 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). > > You also have to report the received packet rate back to other side. > All of this is doable, of course, it's just something that I hope we > don't have to spend time on. > > >> 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) > > Great, thanks. > > By the way, I think all of the UDP tests will either succeed or fail > so you probably don't need to ask for a particular bandwidth but can > just pick a low rate. >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
