Flent-users discussion archives
 help / color / mirror / Atom feed
* [Flent-users] total throughput for rrul test on WiFi
@ 2018-06-25 22:40 Pete Heist
  2018-06-26  8:40 ` Sebastian Moeller
  0 siblings, 1 reply; 3+ messages in thread
From: Pete Heist @ 2018-06-25 22:40 UTC (permalink / raw)
  To: flent-users

The rrul test over a point-to-point WiFi link cuts the total TCP throughput considerably below that of rrul_be. For example, on an 802.11n 20MHz MCS 15 link:

rrul_be: ~90mbit
rrul: ~30-45mbit

I think this came up before, but could the standard rrul test be exceeding the 802.11e spec in terms of how much bandwidth it's using for some access categories? I haven’t found reference to this anywhere, but if so I’ll need to take that into account when interpreting the results. (athstats on Ubiquiti’s gear shows that the counters for all four categories BK, BE, VI and VO go up, so they appear to map evenly with DSCP values BK, BE, CS5 and EF.)

Anyway I think the DSCP field is set to 0 in the backhaul I’m testing for, so rrul tests are probably more of a curiosity in this case...

Pete


_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Flent-users] total throughput for rrul test on WiFi
  2018-06-25 22:40 [Flent-users] total throughput for rrul test on WiFi Pete Heist
@ 2018-06-26  8:40 ` Sebastian Moeller
  2018-06-26  8:58   ` Pete Heist
  0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Moeller @ 2018-06-26  8:40 UTC (permalink / raw)
  To: Pete Heist; +Cc: flent-users

Hi Pete,



> On Jun 26, 2018, at 00:40, Pete Heist <pete@heistp.net> wrote:
> 
> The rrul test over a point-to-point WiFi link cuts the total TCP throughput considerably below that of rrul_be. For example, on an 802.11n 20MHz MCS 15 link:
> 
> rrul_be: ~90mbit
> rrul: ~30-45mbit
> 

	I believe this is simply showing the cost of using the non-aggregating AC_VO that also has an advantage of getting airtime, using that will considerably lower the achievable goodput over the wifi channel. Add to this that with RRUL both ends will send traffic that should be classified AC_VO and the half-duplex nature of current wifi specs and there might simply be much less total goodput available than one would fancy...

> I think this came up before, but could the standard rrul test be exceeding the 802.11e spec in terms of how much bandwidth it's using for some access categories?

	Is there a standard for this?

> I haven’t found reference to this anywhere, but if so I’ll need to take that into account when interpreting the results. (athstats on Ubiquiti’s gear shows that the counters for all four categories BK, BE, VI and VO go up, so they appear to map evenly with DSCP values BK, BE, CS5 and EF.)
> 
> Anyway I think the DSCP field is set to 0 in the backhaul I’m testing for, so rrul tests are probably more of a curiosity in this case...
> 
> Pete
> 
> 
> _______________________________________________
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org


_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Flent-users] total throughput for rrul test on WiFi
  2018-06-26  8:40 ` Sebastian Moeller
@ 2018-06-26  8:58   ` Pete Heist
  0 siblings, 0 replies; 3+ messages in thread
From: Pete Heist @ 2018-06-26  8:58 UTC (permalink / raw)
  To: Sebastian Moeller; +Cc: flent-users



> On Jun 26, 2018, at 10:40 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Pete,
> 
>> On Jun 26, 2018, at 00:40, Pete Heist <pete@heistp.net> wrote:
>> 
>> The rrul test over a point-to-point WiFi link cuts the total TCP throughput considerably below that of rrul_be. For example, on an 802.11n 20MHz MCS 15 link:
>> 
>> rrul_be: ~90mbit
>> rrul: ~30-45mbit
> 
> 	I believe this is simply showing the cost of using the non-aggregating AC_VO that also has an advantage of getting airtime, using that will considerably lower the achievable goodput over the wifi channel. Add to this that with RRUL both ends will send traffic that should be classified AC_VO and the half-duplex nature of current wifi specs and there might simply be much less total goodput available than one would fancy…

Understood...I’m not surprised by the result- it was mainly a lead in to the next part...

> 
>> I think this came up before, but could the standard rrul test be exceeding the 802.11e spec in terms of how much bandwidth it's using for some access categories?
> 
> 	Is there a standard for this?

I should’ve written that more clearly, but that’s what I’m not sure of. I thought I remembered Toke saying before that we may be exceeding some limits with the rrul test on WiFi, but I can’t recall exactly or find a reference to any.

In any case, I won’t treat rrul results as a real-world example of traffic for WiFi. Perhaps there’s an argument to be made that the rrul test should have (or allow) bitrate limits on individual flows, but this opens up more discussion about what constitutes a real-world test that may never fully result in something better than actually doing a real-world test… :)


_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-06-26  8:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-25 22:40 [Flent-users] total throughput for rrul test on WiFi Pete Heist
2018-06-26  8:40 ` Sebastian Moeller
2018-06-26  8:58   ` Pete Heist

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox