Jon, Thanks for your suggestions. I forgot to mention that I am using 802.11a (although I think that the issue is still the same). I understand the half duplex issue you raise, and am okay with that. However, my underlying question of why node A is not sending at the specified rate still exists. A should send as fast as it can regardless of what B (and C) is/are doing. (RTS/CTS is turned off.) Thanks,
Randy On Tue, Apr 27, 2010 at 3:30 PM, Jon Dugan <jdu...@es.net> wrote: > Excerpts from Randy Buck's message of Tue Apr 27 12:23:04 -0500 2010: > > I think I should make something a bit more clear regarding this post. In > > that I am working with a mesh network, I am running these tests over > > multiple hops. For the previous email I sent, I was transferring over 2 > > hops: > > > > A->B->C > > > > I doubt that I am at the capacity of the network card, because when I cut > > the number of hops down to 1: > > > > A->B > > > > I am able to achieve a much high send rate. Here is the same 10Mbps > report, > > only this time for one hop (and yes I am running this many times to make > > sure this isn't an anomaly) : > > ------------------------------------------------------------ > > Client connecting to 5.0.0.9, UDP port 4000 > > Sending 1470 byte datagrams > > UDP buffer size: 112 KByte (default) > > ------------------------------------------------------------ > > [ 3] local 5.0.0.1 port 59795 connected with 5.0.0.9 port 4000 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-10.0 sec 12209 KBytes 10000 Kbits/sec > > [ 3] Sent 8505 datagrams > > [ 3] Server Report: > > [ 3] 0.0-10.0 sec 12198 KBytes 9991 Kbits/sec 0.327 ms 7/ 8504 > > (0.082%) > > [ 3] 0.0-10.0 sec 1 datagrams received out-of-order > > > > > > It seems as though the longer my chain of nodes are, the lower my max > send > > rate can be. The issue is that I am running UDP, which, unlike TCP, > doesn't > > care about reliability (and therefore doesn't send any ACKs). So, why is > > iperf (or something else) causing my maximum send rate to suffer? I will > be > > posting the plateau of one hop as soon as the tests are done. > > In UDP mode Iperf sends as much as it can until it's reached the desired > bitrate or the send() call blocks. So I don't think your problem here is > with > Iperf. > > My intuition about the problem is that it is the turnaround time on the > radio. > IIRC 802.11b is half duplex. When you send a burst from A->B->C, B > receives > the data from A and then pauses receiving from A whilst it sends the data > on > to C. I could be incorrect here, but based on my understanding of your > topology and my recollection of how 802.11b works, I think this is probably > your problem. This sort of behaviour would also explain why longer chains > get > even poorer performance as well. > > Hope that helps, > > Jon > -- > Jon M. Dugan <jdu...@es.net> > ESnet Network Engineering Group > Lawrence Berkeley National Laboratory >
------------------------------------------------------------------------------
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
