<div dir="ltr"><br><div class="gmail_extra">On Mon, Mar 21, 2016 at 6:29 PM, David Lang <span dir="ltr"><<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 29 Feb 2016, Michal Kazior wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Our intent is to continue to improve the flent test suite to be able<br>
to generate repeatable tests, track relevant wifi behaviors and pull<br>
relevant data back, graphed over time (of test) and time (over test<br>
runs). A problem with udp flood tests is that tcp traffic is always<br>
bidirectional (data vs acks), so a naive thought would be, that yes,<br>
you should get half the bandwidth you get with a udp flood test.<br>
</blockquote>
<br>
I don't see why you'd be doomed to get only half the bandwidth because<br>
of that? Sure, Wi-Fi is half-duplex but transmit time for ACKs is a<br>
lot smaller than transmit time for the data.<br>
</blockquote>
<br></span>
The difference is actually far less than you think. Each transmission has a fixed-length header and quiet times that were designed in the days of 802.11b (1-11Mb) and if you are transmitting a wide 802.11ac signal at a couple hundred Mb, you can find that the time taken to transmit even full packets is a surprisingly small percentage of the total transmit time.<span class="HOEnZb"><font color="#888888"><br>
<br>
David Lang</font></span></blockquote><div><br></div><div>A 2-dimensional display of data sent vs. time might be useful, for a couple packets, to help explain this (although it may need to be at log-scale).   X-axis is time, Y is bandwidth being sent.</div><div><br></div><div>-Aaron</div></div></div></div>