In terms of disabling classification and always using best effort,
always passing NULL here to the classifier will do the trick.
http://lxr.free-electrons.com/source/net/mac80211/wme.c#L218
At first glance it does not appear to have *any* default, which
implies that rrul and rrul_be will be
Pete Heist writes:
> On Feb 16, 2017, at 10:03 PM, Sebastian Moeller wrote:
>
> On Feb 16, 2017, at 18:19, Jonathan Morton wrote:
>
> In a sense if there are thresholds for permissible VO/VI traffic fractions
> below which the AP
> On Feb 16, 2017, at 6:19 PM, Jonathan Morton wrote:
>
>> On 16 Feb, 2017, at 18:51, Pete Heist wrote:
>>
>> At first I was thinking to just remove diffserv markings entirely, say with
>> Cake’s besteffort flag, but I think that “good” and
> On 16 Feb, 2017, at 18:51, Pete Heist wrote:
>
> At first I was thinking to just remove diffserv markings entirely, say with
> Cake’s besteffort flag, but I think that “good” and “otherwise unknowing”
> users would suffer, which I think in FreeNet is a vast majority of
> On Feb 16, 2017, at 17:15, Aaron Wood wrote:
>
> The approach that's in all of the Cisco documentation (FWIW) about such
> things for wired networks is that the higher-priority traffic classes for
> VoIP and video are also bandwidth limited to a fraction of the total (and
The approach that's in all of the Cisco documentation (FWIW) about such
things for wired networks is that the higher-priority traffic classes for
VoIP and video are also bandwidth limited to a fraction of the total (and
less than a majority, at that). But that's in an environment where you
> On Feb 16, 2017, at 9:42 AM, Sebastian Moeller wrote:
>
>> On Feb 16, 2017, at 08:57, Pete Heist wrote:
>> [… discussion about DSCP to WMM classes mapping]
>> This always makes me wonder what’s to keep someone from just marking all
>> their traffic 0x7
> On Feb 16, 2017, at 08:57, Pete Heist wrote:
> [… discussion about DSCP to WMM classes mapping]
> This always makes me wonder what’s to keep someone from just marking all
> their traffic 0x7 and stomping over everyone else.
I have a gut feeling that an AP in a
> On Feb 9, 2017, at 3:44 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
>> I’ll mention one example I noticed of the kind of adjustment that
>> probably can’t be done from the qdisc layer today. On page 3 from
>>
> On Feb 1, 2017, at 3:48 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist > writes:
>
>> Few general points on running tests:
>>
>> - Yeah, as you note Flent has a batch facility. Did you not use this
>> simply because you
Aaron Wood writes:
> - Yeah, as you note Flent has a batch facility. Did you not use this
>simply because you couldn't find it, or was there some other reason?
>Would love some feedback on what I can do to make that more useful to
>people... While I have no doubt
Pete Heist writes:
> On Jan 30, 2017, at 10:44 PM, Toke Høiland-Jørgensen wrote:
>
> Oh my, this is quite a lot of tests. Nice :)
>
> It’s also a thumbs up for the ath9k driver changes that nothing went
> wrong during the testing. It takes about 15 hours for
> On Jan 31, 2017, at 12:55 AM, Dave Taht wrote:
>
> * Question #16: Is there any other testing anyone would like to see
> while I have this rig up?
>
> 1) ECN on on both sides.
> 2) A voip test
> 3) P2MP (3 or more stations, rtt_fair_var* tests)
> 4) Lowered MCS rates or
> On Jan 31, 2017, at 12:21 AM, Dave Taht wrote:
>
> A backstory of how I got involved in the bufferbloat effort was that I
> deployed some shiny "new" and "faster" wireless-n radios (6 years
> ago)... and my WISP network in Nicaragua collapsed in rain - which was
> about 6
> On Jan 30, 2017, at 10:44 PM, Toke Høiland-Jørgensen wrote:
>
> Oh my, this is quite a lot of tests. Nice :)
It’s also a thumbs up for the ath9k driver changes that nothing went wrong
during the testing. It takes about 15 hours for a full run and I probably did
that 4-5 times
* Question #16: Is there any other testing anyone would like to see
while I have this rig up?
Please!
1) ECN on on both sides.
2) A voip test
3) P2MP (3 or more stations, rtt_fair_var* tests)
4) Lowered MCS rates or distance or rain
Of these, the last will improve the accuracy and relevance of
> - Yeah, as you note Flent has a batch facility. Did you not use this
> simply because you couldn't find it, or was there some other reason?
> Would love some feedback on what I can do to make that more useful to
> people... While I have no doubt that your 'flenter.py' works, wrapping
> a
Pete Heist writes:
> Hi, I’ve posted some Flent results and analysis for point-to-point Wi-Fi
> using LEDE on OM2P-HS (ath9k):
>
> http://www.drhleny.cz/bufferbloat/wifi_bufferbloat.html
Oh my, this is quite a lot of tests. Nice :)
Few general points on running tests:
-
18 matches
Mail list logo