* [Cerowrt-devel] Managed to break 802.11n (on a 3800)
@ 2014-01-16 15:03 Aaron Wood
2014-01-16 15:29 ` Sebastian Moeller
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Aaron Wood @ 2014-01-16 15:03 UTC (permalink / raw)
To: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 6153 bytes --]
All,
I'm noting this here in case anyone is interested. After I write this up,
I'm going to start from scratch on the configuration, and factory-reset the
router.
=====
The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire
sure what state it's in, but it seems to be only doing HT20 1x1. And in a
fairly broken manner at that.
Running the rrul test (over wifi directly to the router as the netserver),
tcp uploads were 25Mbps or so, but download was 5Mbps. This is me 1-2
meters from the router. Load was never more than 0.33. (I can share the
results of people are interested).
After a full power cycle, wifi isn't coming up at all.
=====
How I got here:
I'm in France, and had dutifully set my unit with the FR country code when
setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms
latency every 10-20 seconds over wifi) on the 5GHz network. The router was
on channel 36, and I wanted to move it up to the far-upper ranges, so I
tried to specify a "custom" channel to do so (140). This was the channel I
thought I had been using with stock (Netgear) firmware.
Wifi didn't come back up after applying the changes, and the luci interface
seemed to be tripping up over stuff that it was reading out of the
configuration files.
I ssh'd in via ethernet, and fixed up the configurations by hand.
Except the driver is still reporting that the 5GHz network won't kick into
802.11n modes, and won't use HT40. It seems to be sure it's configured for
it, but isn't using it.
Further, digging into the rc_stats files with the minstrel speeds, I found
some very odd data (not what I was expecting to see:
(laptop, which can do 2x2 HT40)
rate throughput ewma prob this prob this succ/attempt success
attempts
D 6 6.0 99.9 100.0 2( 2) 65
65
9 0.0 0.0 0.0 0( 0) 0
0
12 2.9 25.0 100.0 0( 0) 1
1
18 4.3 25.0 100.0 0( 0) 1
1
24 5.6 25.0 100.0 0( 0) 1
1
A P 36 32.4 99.9 100.0 0( 0) 51
51
C 48 10.4 25.0 100.0 0( 0) 1
1
B 54 11.5 25.0 100.0 0( 0) 1
1
Total packet count:: ideal 53 lookaround 7
(AppleTV, 1x1 HT20)
root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat
stations/58\:55\:ca\:51\:b5\:4b/rc_stats
rate throughput ewma prob this prob this succ/attempt success
attempts
6 3.5 57.8 100.0 0( 0) 6
6
9 3.9 43.7 100.0 0( 0) 2
2
12 5.1 43.7 100.0 0( 0) 2
2
18 10.0 57.8 100.0 0( 0) 3
3
D 24 13.1 57.8 100.0 0( 0) 3
3
C 36 14.2 43.7 100.0 0( 0) 2
2
B 48 18.2 43.7 100.0 0( 0) 2
2
A P 54 46.2 99.9 100.0 1( 1) 348
367
Total packet count:: ideal 331 lookaround 37
Whereas what I'm seeing for the 2.4GHz radio is:
root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat
10\:9a\:dd\:30\:96\:34/rc_stats
type rate throughput ewma prob this prob retry this
succ/attempt success attempts
CCK/LP 1.0M 0.7 100.0 100.0 0
0( 0) 2 2
CCK/SP 2.0M 0.0 0.0 0.0 0
0( 0) 0 0
CCK/SP 5.5M 0.0 0.0 0.0 0
0( 0) 0 0
CCK/SP 11.0M 0.0 0.0 0.0 0
0( 0) 0 0
HT20/LGI MCS0 5.6 100.0 100.0 1
0( 0) 2 2
HT20/LGI MCS1 0.0 0.0 0.0 0
0( 0) 0 0
HT20/LGI MCS2 0.0 0.0 0.0 0
0( 0) 0 0
HT20/LGI MCS3 0.0 0.0 0.0 0
0( 0) 0 0
HT20/LGI MCS4 0.0 0.0 0.0 0
0( 0) 0 0
HT20/LGI MCS5 30.3 100.0 100.0 5
0( 0) 1 1
HT20/LGI t MCS6 32.5 100.0 100.0 5
0( 0) 11 11
HT20/LGI T P MCS7 35.0 100.0 100.0 5
6( 6) 34 34
Total packet count:: ideal 45 lookaround 3
Average A-MPDU length: 1.3
And here are radio blocks from the current /etc/config/wireless:
config wifi-device 'radio1'
option type 'mac80211'
option macaddr '28:c6:8e:bb:9a:49'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option txpower '17'
option distance '25'
option channel '48'
option country 'US'
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11ng'
option macaddr '28:c6:8e:bb:9a:47'
option htmode 'HT20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option txpower '26'
option country 'FR'
option distance '15'
option channel 'auto'
======
Some notes after having repaired the situation:
- The pci paths to the radios was missing from /etc/config/wireless, that's
the only thing that I saw that seemed grossly out of place.
- Back up and running, and yes, it's much happier, now. Over wifi I get
60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi
has some ugly bufferbloat. (although these results are somewhat in
question when the router has a 1m load average over 5.0...)
- Enabling all the SQM features I was having previously also considerably
cleaned up wifi performance. It's more balanced, but still not nearly as
balanced as I see on gigabit ethernet.
-Aaron
[-- Attachment #2: Type: text/html, Size: 9051 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:03 [Cerowrt-devel] Managed to break 802.11n (on a 3800) Aaron Wood
@ 2014-01-16 15:29 ` Sebastian Moeller
2014-01-16 15:46 ` Aaron Wood
2014-01-16 22:30 ` Dave Taht
2014-01-16 15:38 ` Robert Bradley
2014-01-16 22:08 ` Dave Taht
2 siblings, 2 replies; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 15:29 UTC (permalink / raw)
To: Aaron Wood; +Cc: cerowrt-devel
Hi Aaron,
On Jan 16, 2014, at 16:03 , Aaron Wood <woody77@gmail.com> wrote:
> All,
>
> I'm noting this here in case anyone is interested. After I write this up, I'm going to start from scratch on the configuration, and factory-reset the router.
>
> =====
>
> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire sure what state it's in, but it seems to be only doing HT20 1x1. And in a fairly broken manner at that.
>
> Running the rrul test (over wifi directly to the router as the netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
This is with your mac? Try rrul_noclassification, macosx (at least 10.8) will not do RRUL fair to a fast host. Why I do not know… it always prioritizes the upload, as if it did not see/trust the downstream markings (heck maybe it is busy using all bandwidth for upstream so that it literally never sees the markings on the downstream packets..)
About the other issue I do not know anything…
Best Regards
Sebastian
> This is me 1-2 meters from the router. Load was never more than 0.33. (I can share the results of people are interested).
>
> After a full power cycle, wifi isn't coming up at all.
>
> =====
>
> How I got here:
>
>
> I'm in France, and had dutifully set my unit with the FR country code when setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms latency every 10-20 seconds over wifi) on the 5GHz network. The router was on channel 36, and I wanted to move it up to the far-upper ranges, so I tried to specify a "custom" channel to do so (140). This was the channel I thought I had been using with stock (Netgear) firmware.
>
> Wifi didn't come back up after applying the changes, and the luci interface seemed to be tripping up over stuff that it was reading out of the configuration files.
>
> I ssh'd in via ethernet, and fixed up the configurations by hand.
>
> Except the driver is still reporting that the 5GHz network won't kick into 802.11n modes, and won't use HT40. It seems to be sure it's configured for it, but isn't using it.
>
> Further, digging into the rc_stats files with the minstrel speeds, I found some very odd data (not what I was expecting to see:
>
> (laptop, which can do 2x2 HT40)
> rate throughput ewma prob this prob this succ/attempt success attempts
> D 6 6.0 99.9 100.0 2( 2) 65 65
> 9 0.0 0.0 0.0 0( 0) 0 0
> 12 2.9 25.0 100.0 0( 0) 1 1
> 18 4.3 25.0 100.0 0( 0) 1 1
> 24 5.6 25.0 100.0 0( 0) 1 1
> A P 36 32.4 99.9 100.0 0( 0) 51 51
> C 48 10.4 25.0 100.0 0( 0) 1 1
> B 54 11.5 25.0 100.0 0( 0) 1 1
>
> Total packet count:: ideal 53 lookaround 7
>
> (AppleTV, 1x1 HT20)
> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat stations/58\:55\:ca\:51\:b5\:4b/rc_stats
> rate throughput ewma prob this prob this succ/attempt success attempts
> 6 3.5 57.8 100.0 0( 0) 6 6
> 9 3.9 43.7 100.0 0( 0) 2 2
> 12 5.1 43.7 100.0 0( 0) 2 2
> 18 10.0 57.8 100.0 0( 0) 3 3
> D 24 13.1 57.8 100.0 0( 0) 3 3
> C 36 14.2 43.7 100.0 0( 0) 2 2
> B 48 18.2 43.7 100.0 0( 0) 2 2
> A P 54 46.2 99.9 100.0 1( 1) 348 367
>
> Total packet count:: ideal 331 lookaround 37
>
> Whereas what I'm seeing for the 2.4GHz radio is:
>
> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat 10\:9a\:dd\:30\:96\:34/rc_stats
> type rate throughput ewma prob this prob retry this succ/attempt success attempts
> CCK/LP 1.0M 0.7 100.0 100.0 0 0( 0) 2 2
> CCK/SP 2.0M 0.0 0.0 0.0 0 0( 0) 0 0
> CCK/SP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
> CCK/SP 11.0M 0.0 0.0 0.0 0 0( 0) 0 0
> HT20/LGI MCS0 5.6 100.0 100.0 1 0( 0) 2 2
> HT20/LGI MCS1 0.0 0.0 0.0 0 0( 0) 0 0
> HT20/LGI MCS2 0.0 0.0 0.0 0 0( 0) 0 0
> HT20/LGI MCS3 0.0 0.0 0.0 0 0( 0) 0 0
> HT20/LGI MCS4 0.0 0.0 0.0 0 0( 0) 0 0
> HT20/LGI MCS5 30.3 100.0 100.0 5 0( 0) 1 1
> HT20/LGI t MCS6 32.5 100.0 100.0 5 0( 0) 11 11
> HT20/LGI T P MCS7 35.0 100.0 100.0 5 6( 6) 34 34
>
> Total packet count:: ideal 45 lookaround 3
> Average A-MPDU length: 1.3
>
>
> And here are radio blocks from the current /etc/config/wireless:
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '17'
> option distance '25'
> option channel '48'
> option country 'US'
>
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '26'
> option country 'FR'
> option distance '15'
> option channel 'auto'
>
> ======
>
> Some notes after having repaired the situation:
>
> - The pci paths to the radios was missing from /etc/config/wireless, that's the only thing that I saw that seemed grossly out of place.
>
> - Back up and running, and yes, it's much happier, now. Over wifi I get 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi has some ugly bufferbloat. (although these results are somewhat in question when the router has a 1m load average over 5.0...)
>
> - Enabling all the SQM features I was having previously also considerably cleaned up wifi performance. It's more balanced, but still not nearly as balanced as I see on gigabit ethernet.
>
>
>
> -Aaron
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:03 [Cerowrt-devel] Managed to break 802.11n (on a 3800) Aaron Wood
2014-01-16 15:29 ` Sebastian Moeller
@ 2014-01-16 15:38 ` Robert Bradley
2014-01-16 15:46 ` Aaron Wood
2014-01-16 22:08 ` Dave Taht
2 siblings, 1 reply; 24+ messages in thread
From: Robert Bradley @ 2014-01-16 15:38 UTC (permalink / raw)
To: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
On 16/01/2014 15:03, Aaron Wood wrote:
> All,
>
> I'm noting this here in case anyone is interested. After I write this
> up, I'm going to start from scratch on the configuration, and
> factory-reset the router.
>
> =====
>
> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not
> quire sure what state it's in, but it seems to be only doing HT20 1x1.
> And in a fairly broken manner at that.
>
<snip>
> And here are radio blocks from the current /etc/config/wireless:
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '17'
> option distance '25'
> option channel '48'
> option country 'US'
That's interesting, since it's missing a few configuration options and
seems to be still using the US country code for the 5 GHz interface.
For what it's worth, my router's configuration looks like this (with the
MAC address changed to match your configuration):
config wifi-device 'radio1'
option type 'mac80211'
option channel '36'
option hwmode '11na'
option macaddr '28:c6:8e:bb:9a:49'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option disabled '0'
option txpower '17'
option country 'GB'
option htmode 'HT40+'
I'm using channel 36 and HT40+ here at 17 dBm. This is also from a
UK-based router, so you'll probably want to change the country code from
GB to FR. I'm seeing about 270 Mb/s using Intel wireless (4965AGN) and
Windows 7 about 2.5 m away from the router with those settings.
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '26'
> option country 'FR'
> option distance '15'
> option channel 'auto'
>
My settings for the 2.4 GHz side (deliberately limited to HT20 to avoid
interference):
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11ng'
option macaddr '28:c6:8e:bb:9a:47'
option htmode 'HT20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option disabled '0'
option channel '1'
option country 'GB'
option txpower '20'
This time I'm using channel 1 at 20 dBm. In both of these blocks I'm
leaving the distance option unspecified.
Hope this helps a bit!
--
Robert Bradley
[-- Attachment #2: Type: text/html, Size: 5936 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:38 ` Robert Bradley
@ 2014-01-16 15:46 ` Aaron Wood
0 siblings, 0 replies; 24+ messages in thread
From: Aaron Wood @ 2014-01-16 15:46 UTC (permalink / raw)
To: Robert Bradley; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 3577 bytes --]
They help provide a good counterpoint, thanks! Interesting that yours
don't list the pci path (as mine now do after the reset):
config wifi-device 'radio1'
option type 'mac80211'
option channel '36'
option hwmode '11na'
option path 'pci0000:00/0000:00:12.0'
option htmode 'HT40+'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option txpower '17'
option country 'FR'
-Aaron
On Thu, Jan 16, 2014 at 4:38 PM, Robert Bradley
<robert.bradley1@gmail.com>wrote:
> On 16/01/2014 15:03, Aaron Wood wrote:
>
> All,
>
> I'm noting this here in case anyone is interested. After I write this
> up, I'm going to start from scratch on the configuration, and factory-reset
> the router.
>
> =====
>
> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not
> quire sure what state it's in, but it seems to be only doing HT20 1x1. And
> in a fairly broken manner at that.
>
>
> <snip>
>
>
> And here are radio blocks from the current /etc/config/wireless:
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '17'
> option distance '25'
> option channel '48'
> option country 'US'
>
>
> That's interesting, since it's missing a few configuration options and
> seems to be still using the US country code for the 5 GHz interface. For
> what it's worth, my router's configuration looks like this (with the MAC
> address changed to match your configuration):
>
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option channel '36'
> option hwmode '11na'
>
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option disabled '0'
> option txpower '17'
> option country 'GB'
> option htmode 'HT40+'
>
> I'm using channel 36 and HT40+ here at 17 dBm. This is also from a
> UK-based router, so you'll probably want to change the country code from GB
> to FR. I'm seeing about 270 Mb/s using Intel wireless (4965AGN) and
> Windows 7 about 2.5 m away from the router with those settings.
>
>
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '26'
> option country 'FR'
> option distance '15'
> option channel 'auto'
>
>
> My settings for the 2.4 GHz side (deliberately limited to HT20 to avoid
> interference):
>
>
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option disabled '0'
> option channel '1'
> option country 'GB'
> option txpower '20'
>
> This time I'm using channel 1 at 20 dBm. In both of these blocks I'm
> leaving the distance option unspecified.
>
> Hope this helps a bit!
>
> --
> Robert Bradley
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
[-- Attachment #2: Type: text/html, Size: 7295 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:29 ` Sebastian Moeller
@ 2014-01-16 15:46 ` Aaron Wood
2014-01-16 17:20 ` Sebastian Moeller
2014-01-16 22:30 ` Dave Taht
1 sibling, 1 reply; 24+ messages in thread
From: Aaron Wood @ 2014-01-16 15:46 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
>
> > The 5GHz radio on my 3800 seems to be in a very odd state. I'm not
> quire sure what state it's in, but it seems to be only doing HT20 1x1. And
> in a fairly broken manner at that.
> >
> > Running the rrul test (over wifi directly to the router as the
> netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
>
> This is with your mac? Try rrul_noclassification, macosx (at least
> 10.8) will not do RRUL fair to a fast host. Why I do not know… it always
> prioritizes the upload, as if it did not see/trust the downstream markings
> (heck maybe it is busy using all bandwidth for upstream so that it
> literally never sees the markings on the downstream packets..)
>
> About the other issue I do not know anything...
Sebastian, after sorting out the router, it's still biased, but far less
so, about a 2:1 ratio between upload and download.
Also, my understanding was that with rts/cts, the router was in control of
that aspect of things? So the AP should be able to balance those? (or
perhaps the swamped load on the router is interfering, I'd need another
full-size machine on the wired side of the AP to know for sure.
-Aaron
[-- Attachment #2: Type: text/html, Size: 1521 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:46 ` Aaron Wood
@ 2014-01-16 17:20 ` Sebastian Moeller
2014-01-16 19:08 ` Aaron Wood
0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 17:20 UTC (permalink / raw)
To: Aaron Wood; +Cc: cerowrt-devel
Aaron Wood <woody77@gmail.com> wrote:
>>
>> > The 5GHz radio on my 3800 seems to be in a very odd state. I'm not
>> quire sure what state it's in, but it seems to be only doing HT20
>1x1. And
>> in a fairly broken manner at that.
>> >
>> > Running the rrul test (over wifi directly to the router as the
>> netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
>>
>> This is with your mac? Try rrul_noclassification, macosx (at
>least
>> 10.8) will not do RRUL fair to a fast host. Why I do not know… it
>always
>> prioritizes the upload, as if it did not see/trust the downstream
>markings
>> (heck maybe it is busy using all bandwidth for upstream so that it
>> literally never sees the markings on the downstream packets..)
>>
>> About the other issue I do not know anything...
>
>
>
>Sebastian, after sorting out the router, it's still biased, but far
>less
>so, about a 2:1 ratio between upload and download.
So I See offen 10:1 and worse @165Mbit/s raw wireless rate.
>
>Also, my understanding was that with rts/cts, the router was in control
>of
>that aspect of things?
That is what I thought AS well, but it is not what I See with osx 10.8.
So the AP should be able to balance those? (or
>perhaps the swamped load on the router is interfering, I'd need another
>full-size machine on the wired side of the AP to know for sure.
So if I RRUL from wireless over cerowrt to a wired host in my network I still get the imbalance from macosx, so I assume it is a macos thing...
Best
Sebastian
>
>-Aaron
Hi Aaron
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 17:20 ` Sebastian Moeller
@ 2014-01-16 19:08 ` Aaron Wood
2014-01-16 20:10 ` Sebastian Moeller
2014-01-16 22:35 ` Dave Taht
0 siblings, 2 replies; 24+ messages in thread
From: Aaron Wood @ 2014-01-16 19:08 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
>> Sebastian, after sorting out the router, it's still biased, but far
>> less
>> so, about a 2:1 ratio between upload and download.
>
> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
I get mixed results, but they aren't good. IIRC, apple really changed something about the media access in 10.8, I'll look into that. And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)
>> Also, my understanding was that with rts/cts, the router was in control
>> of
>> that aspect of things?
>
> That is what I thought AS well, but it is not what I See with osx 10.8.
>
It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.
It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).
--Aaron
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 19:08 ` Aaron Wood
@ 2014-01-16 20:10 ` Sebastian Moeller
2014-01-16 21:33 ` Aaron Wood
2014-01-16 22:50 ` Dave Taht
2014-01-16 22:35 ` Dave Taht
1 sibling, 2 replies; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 20:10 UTC (permalink / raw)
To: Aaron Wood; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]
Hi Aaron,
On Jan 16, 2014, at 20:08 , Aaron Wood <woody77@gmail.com> wrote:
>
>>> Sebastian, after sorting out the router, it's still biased, but far
>>> less
>>> so, about a 2:1 ratio between upload and download.
>>
>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
>
> I get mixed results, but they aren't good.
I just checked again and I get crazy results for both RRUL and RRUL_NOCLASSIFICATION:
in both cases I get ~ 10:1 out-in imbalance. And even crazier just had one rrul where both in and out came up almost perfectly at 1:1. Interestingly the classification really works in giving different bandwidth for the different classes. (And in rrul_noclassification, where the still classified UDP probes make it through the EF flow gets shorter latencies…).
Note that measuring through cerowrt to a wired host (with too restrictive firewall settings) get:
with the MacBooks uplink still dominant (actually continually getting more bandwidth…). Since I my only wireless connected machines are macs and nobody else complained about this issue I assume it is an osx issue
For comparison an RRUL test from the wired linux host to cerowrt, where things look much better...
> IIRC, apple really changed something about the media access in 10.8, I'll look into that. And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)
Yeah, good question whether this is the same in all macosx versions? (Sonner or later I will switch to 10.9 and repeat the measurements…) The saving grace is that I usually either upload or download at home between my 2 computers so I rarely feel the full force of this unfortunate macosx behavior. Just checked using SMB to copy a file to the wired machine and from the wired machine at the same time, nicely splits the bandwidth evenly between up and download, so this might be netsurf related...
>
>
>>> Also, my understanding was that with rts/cts, the router was in control
>>> of
>>> that aspect of things?
>>
>> That is what I thought AS well, but it is not what I See with osx 10.8.
>>
>
> It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.
I think we agree that the AP should show more self-confidence and reject such requests more firmly :)
>
> It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).
I am not really equipped to do this, with just one wireless notebook at my disposal :)
best
Sebastian
>
> --Aaron
[-- Attachment #2.1: Type: text/html, Size: 4747 bytes --]
[-- Attachment #2.2: rrul_noclassification_macbook_2_cerowrt_5GHz.png --]
[-- Type: image/png, Size: 119948 bytes --]
[-- Attachment #2.3: rrul_macbook_2_cerowrt_5GHz.png --]
[-- Type: image/png, Size: 95405 bytes --]
[-- Attachment #2.4: rrul_macbook_2_cerowrt_2_happy-horse_5GHz.png --]
[-- Type: image/png, Size: 76496 bytes --]
[-- Attachment #2.5: rrul_noclassification_macbook_2_cerowrt_2_happy-horse_5GHz.png --]
[-- Type: image/png, Size: 69206 bytes --]
[-- Attachment #2.6: PastedGraphic-2.tiff --]
[-- Type: image/tiff, Size: 1101654 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 20:10 ` Sebastian Moeller
@ 2014-01-16 21:33 ` Aaron Wood
2014-01-16 22:50 ` Dave Taht
1 sibling, 0 replies; 24+ messages in thread
From: Aaron Wood @ 2014-01-16 21:33 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Thu, Jan 16, 2014 at 9:10 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Aaron,
>
> I just checked again and I get crazy results for both RRUL and
> RRUL_NOCLASSIFICATION:
>
Yes, those look a like my results (after having gotten things running).
When broken, it was still imbalanced, but the overall speeds were 11g, not
HT40 11n.
(I'll put up graphs tomorrow)
-Aaron
[-- Attachment #2: Type: text/html, Size: 1238 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:03 [Cerowrt-devel] Managed to break 802.11n (on a 3800) Aaron Wood
2014-01-16 15:29 ` Sebastian Moeller
2014-01-16 15:38 ` Robert Bradley
@ 2014-01-16 22:08 ` Dave Taht
2 siblings, 0 replies; 24+ messages in thread
From: Dave Taht @ 2014-01-16 22:08 UTC (permalink / raw)
To: Aaron Wood; +Cc: cerowrt-devel
Several quick notes:
(I am behind on my mail)
On Thu, Jan 16, 2014 at 10:03 AM, Aaron Wood <woody77@gmail.com> wrote:
> All,
>
> I'm noting this here in case anyone is interested. After I write this up,
> I'm going to start from scratch on the configuration, and factory-reset the
> router.
>
> =====
>
> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire
> sure what state it's in, but it seems to be only doing HT20 1x1. And in a
> fairly broken manner at that.
Well, I've noted that until we get per station queueing in the ath9k driver
itself, wifi performance is not going to be very good.
> Running the rrul test (over wifi directly to the router as the netserver),
> tcp uploads were 25Mbps or so, but download was 5Mbps. This is me 1-2
> meters from the router. Load was never more than 0.33. (I can share the
> results of people are interested).
One set of parameters worth fiddling with are the defaults for aggregation
in /usr/sbin/debloat which historically have been set very low for the best
balance of latency and performance.
Presently those are set to:
["qlen_vo"] = 2,
["qlen_vi"] = 4,
["qlen_be"] = 12,
["qlen_bk"] = 12,
change it to
["qlen_vi"] = 12,
["qlen_be"] = 128,
["qlen_bk"] = 128,
Your bandwidth should go up (unless there's a genuine problem
elsewhere), and your latency go to hell.
Another (better) idea is to use a better filter (problem in creating
such noted in an earlier email) that
only sorts on destination ips, with a bigger quantum. I haven't had
any success in creating that filter.
That +
I have long thought that for wifi, a quantum of 1514, or double or
treble that, was a better idea than the current defaults, *given the
underlying driver infrastructure*, and NOT in the presence of
wireless-g.
change this to something else
["CODEL_LL_QUANTUM"] = 300
then you can run
IFACE=sw00 QMODEL=fq_codel_ll /usr/sbin/debloat # for 2.4ghz
(you can also fiddle with all of these params on the command line
qlen_vi=12 qlen_be=64 qlen_bk=64 IFACE=sw00 QMODEL=fq_codel_ll /usr/sbin/debloat
A third, if you are running linux on the client, is to run fq_codel on it's
wifi interfaces via the debloat script as well. There's tons of latency
hidden in everybody's wifi drivers, and part of your problem is
coming from that.
But the up/down ratio problem you are seeing is pretty real.
>
> After a full power cycle, wifi isn't coming up at all.
The channel you selected is not legal in country "FR". (I didn't know if any
5ghz was legal yet at all in FR(?))
> =====
>
> How I got here:
>
>
> I'm in France, and had dutifully set my unit with the FR country code when
> setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms
> latency every 10-20 seconds over wifi) on the 5GHz network. The router was
> on channel 36, and I wanted to move it up to the far-upper ranges, so I
> tried to specify a "custom" channel to do so (140). This was the channel I
> thought I had been using with stock (Netgear) firmware.
Well, it's rejected by the registration database.
http://wireless.kernel.org/en/developers/Regulatory
arguably the gui should reject attempts to select channels not in the database.
140 isn't legal in the US either, so far as I recall.
you should definitely also have a consistent country code per radio.
> Wifi didn't come back up after applying the changes, and the luci interface
> seemed to be tripping up over stuff that it was reading out of the
> configuration files.
>
> I ssh'd in via ethernet, and fixed up the configurations by hand.
>
> Except the driver is still reporting that the 5GHz network won't kick into
> 802.11n modes, and won't use HT40. It seems to be sure it's configured for
> it, but isn't using it.
Might be being rejected as before.
>
> Further, digging into the rc_stats files with the minstrel speeds, I found
> some very odd data (not what I was expecting to see:
>
> (laptop, which can do 2x2 HT40)
> rate throughput ewma prob this prob this succ/attempt success
> attempts
> D 6 6.0 99.9 100.0 2( 2) 65
> 65
> 9 0.0 0.0 0.0 0( 0) 0
> 0
> 12 2.9 25.0 100.0 0( 0) 1
> 1
> 18 4.3 25.0 100.0 0( 0) 1
> 1
> 24 5.6 25.0 100.0 0( 0) 1
> 1
> A P 36 32.4 99.9 100.0 0( 0) 51
> 51
> C 48 10.4 25.0 100.0 0( 0) 1
> 1
> B 54 11.5 25.0 100.0 0( 0) 1
> 1
>
> Total packet count:: ideal 53 lookaround 7
>
> (AppleTV, 1x1 HT20)
> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat
> stations/58\:55\:ca\:51\:b5\:4b/rc_stats
> rate throughput ewma prob this prob this succ/attempt success
> attempts
> 6 3.5 57.8 100.0 0( 0) 6
> 6
> 9 3.9 43.7 100.0 0( 0) 2
> 2
> 12 5.1 43.7 100.0 0( 0) 2
> 2
> 18 10.0 57.8 100.0 0( 0) 3
> 3
> D 24 13.1 57.8 100.0 0( 0) 3
> 3
> C 36 14.2 43.7 100.0 0( 0) 2
> 2
> B 48 18.2 43.7 100.0 0( 0) 2
> 2
> A P 54 46.2 99.9 100.0 1( 1) 348
> 367
>
> Total packet count:: ideal 331 lookaround 37
>
> Whereas what I'm seeing for the 2.4GHz radio is:
>
> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat
> 10\:9a\:dd\:30\:96\:34/rc_stats
> type rate throughput ewma prob this prob retry this
> succ/attempt success attempts
> CCK/LP 1.0M 0.7 100.0 100.0 0
> 0( 0) 2 2
> CCK/SP 2.0M 0.0 0.0 0.0 0
> 0( 0) 0 0
> CCK/SP 5.5M 0.0 0.0 0.0 0
> 0( 0) 0 0
> CCK/SP 11.0M 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS0 5.6 100.0 100.0 1
> 0( 0) 2 2
> HT20/LGI MCS1 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS2 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS3 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS4 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS5 30.3 100.0 100.0 5
> 0( 0) 1 1
> HT20/LGI t MCS6 32.5 100.0 100.0 5
> 0( 0) 11 11
> HT20/LGI T P MCS7 35.0 100.0 100.0 5
> 6( 6) 34 34
>
> Total packet count:: ideal 45 lookaround 3
> Average A-MPDU length: 1.3
>
>
> And here are radio blocks from the current /etc/config/wireless:
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '17'
> option distance '25'
> option channel '48'
> option country 'US'
>
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '26'
> option country 'FR'
> option distance '15'
> option channel 'auto'
>
> ======
>
> Some notes after having repaired the situation:
>
> - The pci paths to the radios was missing from /etc/config/wireless, that's
> the only thing that I saw that seemed grossly out of place.
>
> - Back up and running, and yes, it's much happier, now. Over wifi I get
> 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi
> has some ugly bufferbloat. (although these results are somewhat in question
> when the router has a 1m load average over 5.0...)
>
> - Enabling all the SQM features I was having previously also considerably
> cleaned up wifi performance. It's more balanced, but still not nearly as
> balanced as I see on gigabit ethernet.
>
>
>
> -Aaron
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 15:29 ` Sebastian Moeller
2014-01-16 15:46 ` Aaron Wood
@ 2014-01-16 22:30 ` Dave Taht
2014-01-16 22:56 ` Sebastian Moeller
1 sibling, 1 reply; 24+ messages in thread
From: Dave Taht @ 2014-01-16 22:30 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
On Thu, Jan 16, 2014 at 10:29 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Aaron,
>
> On Jan 16, 2014, at 16:03 , Aaron Wood <woody77@gmail.com> wrote:
>
>> All,
>>
>> I'm noting this here in case anyone is interested. After I write this up, I'm going to start from scratch on the configuration, and factory-reset the router.
>>
>> =====
>>
>> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire sure what state it's in, but it seems to be only doing HT20 1x1. And in a fairly broken manner at that.
>>
>> Running the rrul test (over wifi directly to the router as the netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
>
> This is with your mac? Try rrul_noclassification, macosx (at least 10.8) will not do RRUL fair to a fast host. Why I do not know… it always prioritizes the upload, as if it did not see/trust the downstream markings (heck maybe it is busy using all bandwidth for upstream so that it literally never sees the markings on the downstream packets..)
rrul with classification blows up 802.11e on all devices, everywhere.
The VO and VI queues generally get all the bandwidth.
Been saying that a while. VO and VI should be strictly admission
controlled and are not, anywhere. All the queues fill
and bad things happen. What should happen in a 802.11n world is that a
set of packets should wind up in the best queue for the TXOP, and VO
used not at all.
rrul_noclassification better looks like the intent for classification
was for 802.11e and thus works better. There are a couple
other tests in the netperf-wrapper suite that don't use classification
at all, that might be saner to use.
lastly, if you are doing a test over the internet, many providers pee
on the tos bits. Unless you've done a packet capture, you can't trust
that you are actually seeing classified packets coming back from the
internet.
One of the things I hope to fix with the twd effort is to detect tos
bit preservation and note it in the test.
I'm delighted you'all are seeing these results for yourselves. Getting
dinged on bandwidth after aiming for low latency by the public is not
something I'd wanted to happen with a "stable" release. Regrettably
fixing the drivers to work better only has
felix working on it in his spare time, and I've been trying to clear
my plate for months to help do the delicate rework
required. (or recruit others to help)
> About the other issue I do not know anything…
>
> Best Regards
> Sebastian
>
>> This is me 1-2 meters from the router. Load was never more than 0.33. (I can share the results of people are interested).
>>
>> After a full power cycle, wifi isn't coming up at all.
>>
>> =====
>>
>> How I got here:
>>
>>
>> I'm in France, and had dutifully set my unit with the FR country code when setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms latency every 10-20 seconds over wifi) on the 5GHz network. The router was on channel 36, and I wanted to move it up to the far-upper ranges, so I tried to specify a "custom" channel to do so (140). This was the channel I thought I had been using with stock (Netgear) firmware.
>>
>> Wifi didn't come back up after applying the changes, and the luci interface seemed to be tripping up over stuff that it was reading out of the configuration files.
>>
>> I ssh'd in via ethernet, and fixed up the configurations by hand.
>>
>> Except the driver is still reporting that the 5GHz network won't kick into 802.11n modes, and won't use HT40. It seems to be sure it's configured for it, but isn't using it.
>>
>> Further, digging into the rc_stats files with the minstrel speeds, I found some very odd data (not what I was expecting to see:
>>
>> (laptop, which can do 2x2 HT40)
>> rate throughput ewma prob this prob this succ/attempt success attempts
>> D 6 6.0 99.9 100.0 2( 2) 65 65
>> 9 0.0 0.0 0.0 0( 0) 0 0
>> 12 2.9 25.0 100.0 0( 0) 1 1
>> 18 4.3 25.0 100.0 0( 0) 1 1
>> 24 5.6 25.0 100.0 0( 0) 1 1
>> A P 36 32.4 99.9 100.0 0( 0) 51 51
>> C 48 10.4 25.0 100.0 0( 0) 1 1
>> B 54 11.5 25.0 100.0 0( 0) 1 1
>>
>> Total packet count:: ideal 53 lookaround 7
>>
>> (AppleTV, 1x1 HT20)
>> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat stations/58\:55\:ca\:51\:b5\:4b/rc_stats
>> rate throughput ewma prob this prob this succ/attempt success attempts
>> 6 3.5 57.8 100.0 0( 0) 6 6
>> 9 3.9 43.7 100.0 0( 0) 2 2
>> 12 5.1 43.7 100.0 0( 0) 2 2
>> 18 10.0 57.8 100.0 0( 0) 3 3
>> D 24 13.1 57.8 100.0 0( 0) 3 3
>> C 36 14.2 43.7 100.0 0( 0) 2 2
>> B 48 18.2 43.7 100.0 0( 0) 2 2
>> A P 54 46.2 99.9 100.0 1( 1) 348 367
>>
No AMPDUs. Hmm. Might be a bug.
>> Total packet count:: ideal 331 lookaround 37
Hmm. The radios are set for HT20 for the 2.4ghz and HT40+ for the
5ghz. I note that
HT40 in wireless-n the 8 channels used up need to be congruent.
HT40+ is 36+40, and 44+48 for example. You can't do 40+44.
Availability of HTXX is dependent upon your regulatory domain.
>> Whereas what I'm seeing for the 2.4GHz radio is:
>>
>> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat 10\:9a\:dd\:30\:96\:34/rc_stats
>> type rate throughput ewma prob this prob retry this succ/attempt success attempts
>> CCK/LP 1.0M 0.7 100.0 100.0 0 0( 0) 2 2
>> CCK/SP 2.0M 0.0 0.0 0.0 0 0( 0) 0 0
>> CCK/SP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
>> CCK/SP 11.0M 0.0 0.0 0.0 0 0( 0) 0 0
>> HT20/LGI MCS0 5.6 100.0 100.0 1 0( 0) 2 2
>> HT20/LGI MCS1 0.0 0.0 0.0 0 0( 0) 0 0
>> HT20/LGI MCS2 0.0 0.0 0.0 0 0( 0) 0 0
>> HT20/LGI MCS3 0.0 0.0 0.0 0 0( 0) 0 0
>> HT20/LGI MCS4 0.0 0.0 0.0 0 0( 0) 0 0
>> HT20/LGI MCS5 30.3 100.0 100.0 5 0( 0) 1 1
>> HT20/LGI t MCS6 32.5 100.0 100.0 5 0( 0) 11 11
>> HT20/LGI T P MCS7 35.0 100.0 100.0 5 6( 6) 34 34
>>
>> Total packet count:: ideal 45 lookaround 3
>> Average A-MPDU length: 1.3
You are doing good at the highest possible rate. However packet
aggregation is pretty terrible.
>>
>> And here are radio blocks from the current /etc/config/wireless:
>>
>> config wifi-device 'radio1'
>> option type 'mac80211'
>> option macaddr '28:c6:8e:bb:9a:49'
>> list ht_capab 'SHORT-GI-40'
>> list ht_capab 'TX-STBC'
>> list ht_capab 'RX-STBC1'
>> list ht_capab 'DSSS_CCK-40'
>> option txpower '17'
>> option distance '25'
>> option channel '48'
>> option country 'US'
>>
>> config wifi-device 'radio0'
>> option type 'mac80211'
>> option hwmode '11ng'
>> option macaddr '28:c6:8e:bb:9a:47'
>> option htmode 'HT20'
>> list ht_capab 'SHORT-GI-40'
>> list ht_capab 'TX-STBC'
>> list ht_capab 'RX-STBC1'
>> list ht_capab 'DSSS_CCK-40'
>> option txpower '26'
>> option country 'FR'
>> option distance '15'
>> option channel 'auto'
I don't know anyone that has fiddled with distance to such an extent.
your country codes need to be the same and you should look at what
is allowed in FR.
>> ======
>>
>> Some notes after having repaired the situation:
>>
>> - The pci paths to the radios was missing from /etc/config/wireless, that's the only thing that I saw that seemed grossly out of place.
>>
>> - Back up and running, and yes, it's much happier, now. Over wifi I get 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi has some ugly bufferbloat. (although these results are somewhat in question when the router has a 1m load average over 5.0...)
Trying to measure the one way delay here is important (and hard. The
only tool I've found for it so far was owamp, so I'm trying to write
that test in twd). A TON of your delay is coming from your client. A
network connection is like a fountain, or a toilet, both sides of the
flow count...
>>
>> - Enabling all the SQM features I was having previously also considerably cleaned up wifi performance. It's more balanced, but still not nearly as balanced as I see on gigabit ethernet.
>>
>>
>>
>> -Aaron
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 19:08 ` Aaron Wood
2014-01-16 20:10 ` Sebastian Moeller
@ 2014-01-16 22:35 ` Dave Taht
1 sibling, 0 replies; 24+ messages in thread
From: Dave Taht @ 2014-01-16 22:35 UTC (permalink / raw)
To: Aaron Wood; +Cc: cerowrt-devel
On Thu, Jan 16, 2014 at 2:08 PM, Aaron Wood <woody77@gmail.com> wrote:
>
>>> Sebastian, after sorting out the router, it's still biased, but far
>>> less
>>> so, about a 2:1 ratio between upload and download.
>>
>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
>
> I get mixed results, but they aren't good. IIRC, apple really changed something about the media access in 10.8, I'll look into that. And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)
>
>
>>> Also, my understanding was that with rts/cts, the router was in control
>>> of
>>> that aspect of things?
>>
>> That is what I thought AS well, but it is not what I See with osx 10.8.
>>
>
> It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.
Um, probably not. Both station and AP are doing EDCA scheduling, (I'd
hope) which was originally a p2p style protocol. So it
is kind of overly "fair" to both. The client is doing better
aggregation since it is only going one way, the AP has trouble with
aggregation due to lack of per station queueing.
folk have done work to try and give the APs more priority and looking
at that has also long been on the todo list.
> It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).
but do check. I generally get terrible results from macos, and the
intel wifi chip in the laptop. the ath9k in another laptop is
considerably better, and ath10k (on the nuc) is not horrible. It's
terrible on both ends, on this test and both the clients and the APs
need a ton of work...
> --Aaron
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 20:10 ` Sebastian Moeller
2014-01-16 21:33 ` Aaron Wood
@ 2014-01-16 22:50 ` Dave Taht
2014-01-16 23:15 ` Sebastian Moeller
1 sibling, 1 reply; 24+ messages in thread
From: Dave Taht @ 2014-01-16 22:50 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
[-- Attachment #1.1: Type: text/plain, Size: 5535 bytes --]
On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Aaron,
>
>
> On Jan 16, 2014, at 20:08 , Aaron Wood <woody77@gmail.com> wrote:
>
>
> Sebastian, after sorting out the router, it's still biased, but far
> less
> so, about a 2:1 ratio between upload and download.
>
>
> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
>
>
> I get mixed results, but they aren't good.
>
>
It's hard to comment on each graph in email, but I'll try.
I generally run rrul with the --disable-log option. Log scales helped back
when we were still
comparing against pfifo fast.
The really bad download graph. "Crazy results"
Download bandwith is bad because the upload starts and fills the queue
first, the download
has to wait to fill the queue and generally gets dropped earlier than the
upload. This is
one of the many reasons I don't care for IW10....
The upload gets better slowly due to how slow tcp is ramping up over the
half-duplex
wifi channel.
>
> I just checked again and I get crazy results for both RRUL and
> RRUL_NOCLASSIFICATION:
>
> in both cases I get ~ 10:1 out-in imbalance.
>
I think that with a larger quantum on the AP they will be in less
imbalance, and you should try nfq_codel also.
The larger quantum will also hurt, too.... right answer has always been per
station queues.
> And even crazier just had one rrul where both in and out came up almost
> perfectly at 1:1
>
Hmm. Wifi is weird, isn't it? It's not like ethernet at all. Too bad the
universe insists on trying to
defy the laws of physics by trying to make it act like ethernet....
> . Interestingly the classification really works in giving different
> bandwidth for the different classes. (And in rrul_noclassification, where
> the still classified UDP probes make it through the EF flow gets shorter
> latencies…).
>
having 4 full queues and a txop each is far worse than 1 queue with better
aggregation, IMHO.
>
> Note that measuring through cerowrt to a wired host (with too restrictive
> firewall settings) get:
>
You are seeing the upload ramp up along tcp's lines and the download ramp
down as it gets progressively more starved.
> with the MacBooks uplink still dominant (actually continually getting more
> bandwidth…).
>
Well, you only have X bandwidth, in the air, total. A better way of saying
it might be the macbook is taking better advantage
of it's txops to ship more data in an aggregate.
Since I my only wireless connected machines are macs and nobody else
> complained about this issue I assume it is an osx issue
>
I honestly think that aside from benchmarks, bandwidth is irrelevant on
wifi. Lower latency is something that you
actually feel, and when accessing the web or doing a videoconference,
that's the part that matters.
it IS possible to get the best of both worlds, but that's going to take
some driver rework.
>
> For comparison an RRUL test from the wired linux host to cerowrt, where
> things look much better...
>
>
>
> IIRC, apple really changed something about the media access in 10.8, I'll
> look into that. And see if my wife will let me install netperf on her
> laptop (I think it's still running 10.7)
>
>
> Yeah, good question whether this is the same in all macosx versions?
> (Sonner or later I will switch to 10.9 and repeat the measurements…) The
> saving grace is that I usually either upload or download at home between my
> 2 computers so I rarely feel the full force of this unfortunate macosx
> behavior. Just checked using SMB to copy a file to the wired machine and
> from the wired machine at the same time, nicely splits the bandwidth evenly
> between up and download, so this might be netsurf related...
>
>
Single threaded tests will generally work ok, which is why nobody before
has complained... which is why rrul exists to beat up things like
torrent-like ,web like videoconferencing-like and voip-like behaviors.
>
>
> Also, my understanding was that with rts/cts, the router was in control
> of
> that aspect of things?
>
>
> That is what I thought AS well, but it is not what I See with osx 10.8.
>
>
> It may be a case of the station aggressively asking to send, and the AP
> granting instead of sending data to the station that's waiting.
>
>
> I think we agree that the AP should show more self-confidence and reject
> such requests more firmly :)
>
>
>
> It should be clear in a monitor-mode tcpdump (or a statistical summary of
> packets).
>
>
> I am not really equipped to do this, with just one wireless notebook at my
> disposal :)
>
> best
> Sebastian
>
>
Now that you have your laptops running this stuff (AWESOME thank you!)
If I can encourage you all to go outside, to like your nearest cybercafe,
or conference center, and run your rrul tests there...
... you'll find out just how bad the rest of the world is... (and get some
good data).
I routinely see 4-6 seconds of latency, and a bare megabit or two of actual
bandwidth. The ONLY place Iv'e ever had decent wifi performance in a busy
area has been at ietf conferences....
>
> --Aaron
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
--
Dave Täht
Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
[-- Attachment #1.2: Type: text/html, Size: 9766 bytes --]
[-- Attachment #2: rrul_macbook_2_cerowrt_5GHz.png --]
[-- Type: image/png, Size: 95405 bytes --]
[-- Attachment #3: rrul_noclassification_macbook_2_cerowrt_2_happy-horse_5GHz.png --]
[-- Type: image/png, Size: 69206 bytes --]
[-- Attachment #4: rrul_macbook_2_cerowrt_2_happy-horse_5GHz.png --]
[-- Type: image/png, Size: 76496 bytes --]
[-- Attachment #5: rrul_noclassification_macbook_2_cerowrt_5GHz.png --]
[-- Type: image/png, Size: 119948 bytes --]
[-- Attachment #6: PastedGraphic-2.tiff --]
[-- Type: image/tiff, Size: 1101654 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 22:30 ` Dave Taht
@ 2014-01-16 22:56 ` Sebastian Moeller
2014-01-16 23:12 ` Dave Taht
0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 22:56 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 11679 bytes --]
Hi Dave,
many thanks for all the information & elucidation, as always.
On Jan 16, 2014, at 23:30 , Dave Taht <dave.taht@gmail.com> wrote:
> On Thu, Jan 16, 2014 at 10:29 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Aaron,
>>
>> On Jan 16, 2014, at 16:03 , Aaron Wood <woody77@gmail.com> wrote:
>>
>>> All,
>>>
>>> I'm noting this here in case anyone is interested. After I write this up, I'm going to start from scratch on the configuration, and factory-reset the router.
>>>
>>> =====
>>>
>>> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire sure what state it's in, but it seems to be only doing HT20 1x1. And in a fairly broken manner at that.
>>>
>>> Running the rrul test (over wifi directly to the router as the netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
>>
>> This is with your mac? Try rrul_noclassification, macosx (at least 10.8) will not do RRUL fair to a fast host. Why I do not know… it always prioritizes the upload, as if it did not see/trust the downstream markings (heck maybe it is busy using all bandwidth for upstream so that it literally never sees the markings on the downstream packets..)
>
> rrul with classification blows up 802.11e on all devices, everywhere.
> The VO and VI queues generally get all the bandwidth.
> Been saying that a while. VO and VI should be strictly admission
> controlled and are not, anywhere. All the queues fill
> and bad things happen. What should happen in a 802.11n world is that a
> set of packets should wind up in the best queue for the TXOP, and VO
> used not at all.
>
> rrul_noclassification better looks like the intent for classification
> was for 802.11e and thus works better. There are a couple
> other tests in the netperf-wrapper suite that don't use classification
> at all, that might be saner to use.
Ah, so in rrul_noclassification, the UDP flows still are tos marked (at least that is reported in the plots and visible in the plots), but even using tcp_bidirectional I see a crazy imbalance 80:1, so this laptop's Broadcom BCM43xx (apple is not as informative as I would like about the components, but the firmware marker points at broadcom I would say) isn't better than the intel wifi in your's I would say…
>
> lastly, if you are doing a test over the internet, many providers pee
> on the tos bits. Unless you've done a packet capture, you can't trust
> that you are actually seeing classified packets coming back from the
> internet.
Good point, comparing just the local rrul plots with the ones to demo, I see what you mean, there is a tiny bit of the priority classes visible in the uplink (bur barely) and none at all in the downlink, so my ISP does not think too much of the toe bits (I guess the tos effect on the uplink is from what cero is doing and since cero controls the bottleneck some "imprint" remains to be seen at packet reception time at demo, or so I think...).
>
> One of the things I hope to fix with the twd effort is to detect tos
> bit preservation and note it in the test.
>
> I'm delighted you'all are seeing these results for yourselves. Getting
> dinged on bandwidth after aiming for low latency by the public is not
> something I'd wanted to happen with a "stable" release. Regrettably
> fixing the drivers to work better only has
> felix working on it in his spare time, and I've been trying to clear
> my plate for months to help do the delicate rework
> required. (or recruit others to help)
I would love to help, but this is far out of my league and area of expertise…
best
Sebastian
>
>
>> About the other issue I do not know anything…
>>
>> Best Regards
>> Sebastian
>>
>>> This is me 1-2 meters from the router. Load was never more than 0.33. (I can share the results of people are interested).
>>>
>>> After a full power cycle, wifi isn't coming up at all.
>>>
>>> =====
>>>
>>> How I got here:
>>>
>>>
>>> I'm in France, and had dutifully set my unit with the FR country code when setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms latency every 10-20 seconds over wifi) on the 5GHz network. The router was on channel 36, and I wanted to move it up to the far-upper ranges, so I tried to specify a "custom" channel to do so (140). This was the channel I thought I had been using with stock (Netgear) firmware.
>>>
>>> Wifi didn't come back up after applying the changes, and the luci interface seemed to be tripping up over stuff that it was reading out of the configuration files.
>>>
>>> I ssh'd in via ethernet, and fixed up the configurations by hand.
>>>
>>> Except the driver is still reporting that the 5GHz network won't kick into 802.11n modes, and won't use HT40. It seems to be sure it's configured for it, but isn't using it.
>>>
>>> Further, digging into the rc_stats files with the minstrel speeds, I found some very odd data (not what I was expecting to see:
>>>
>>> (laptop, which can do 2x2 HT40)
>>> rate throughput ewma prob this prob this succ/attempt success attempts
>>> D 6 6.0 99.9 100.0 2( 2) 65 65
>>> 9 0.0 0.0 0.0 0( 0) 0 0
>>> 12 2.9 25.0 100.0 0( 0) 1 1
>>> 18 4.3 25.0 100.0 0( 0) 1 1
>>> 24 5.6 25.0 100.0 0( 0) 1 1
>>> A P 36 32.4 99.9 100.0 0( 0) 51 51
>>> C 48 10.4 25.0 100.0 0( 0) 1 1
>>> B 54 11.5 25.0 100.0 0( 0) 1 1
>>>
>>> Total packet count:: ideal 53 lookaround 7
>>>
>>> (AppleTV, 1x1 HT20)
>>> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat stations/58\:55\:ca\:51\:b5\:4b/rc_stats
>>> rate throughput ewma prob this prob this succ/attempt success attempts
>>> 6 3.5 57.8 100.0 0( 0) 6 6
>>> 9 3.9 43.7 100.0 0( 0) 2 2
>>> 12 5.1 43.7 100.0 0( 0) 2 2
>>> 18 10.0 57.8 100.0 0( 0) 3 3
>>> D 24 13.1 57.8 100.0 0( 0) 3 3
>>> C 36 14.2 43.7 100.0 0( 0) 2 2
>>> B 48 18.2 43.7 100.0 0( 0) 2 2
>>> A P 54 46.2 99.9 100.0 1( 1) 348 367
>>>
>
> No AMPDUs. Hmm. Might be a bug.
>
>>> Total packet count:: ideal 331 lookaround 37
>
> Hmm. The radios are set for HT20 for the 2.4ghz and HT40+ for the
> 5ghz. I note that
> HT40 in wireless-n the 8 channels used up need to be congruent.
>
> HT40+ is 36+40, and 44+48 for example. You can't do 40+44.
>
> Availability of HTXX is dependent upon your regulatory domain.
>
>>> Whereas what I'm seeing for the 2.4GHz radio is:
>>>
>>> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat 10\:9a\:dd\:30\:96\:34/rc_stats
>>> type rate throughput ewma prob this prob retry this succ/attempt success attempts
>>> CCK/LP 1.0M 0.7 100.0 100.0 0 0( 0) 2 2
>>> CCK/SP 2.0M 0.0 0.0 0.0 0 0( 0) 0 0
>>> CCK/SP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
>>> CCK/SP 11.0M 0.0 0.0 0.0 0 0( 0) 0 0
>>> HT20/LGI MCS0 5.6 100.0 100.0 1 0( 0) 2 2
>>> HT20/LGI MCS1 0.0 0.0 0.0 0 0( 0) 0 0
>>> HT20/LGI MCS2 0.0 0.0 0.0 0 0( 0) 0 0
>>> HT20/LGI MCS3 0.0 0.0 0.0 0 0( 0) 0 0
>>> HT20/LGI MCS4 0.0 0.0 0.0 0 0( 0) 0 0
>>> HT20/LGI MCS5 30.3 100.0 100.0 5 0( 0) 1 1
>>> HT20/LGI t MCS6 32.5 100.0 100.0 5 0( 0) 11 11
>>> HT20/LGI T P MCS7 35.0 100.0 100.0 5 6( 6) 34 34
>>>
>>> Total packet count:: ideal 45 lookaround 3
>>> Average A-MPDU length: 1.3
>
> You are doing good at the highest possible rate. However packet
> aggregation is pretty terrible.
>
>>>
>>> And here are radio blocks from the current /etc/config/wireless:
>>>
>>> config wifi-device 'radio1'
>>> option type 'mac80211'
>>> option macaddr '28:c6:8e:bb:9a:49'
>>> list ht_capab 'SHORT-GI-40'
>>> list ht_capab 'TX-STBC'
>>> list ht_capab 'RX-STBC1'
>>> list ht_capab 'DSSS_CCK-40'
>>> option txpower '17'
>>> option distance '25'
>>> option channel '48'
>>> option country 'US'
>>>
>>> config wifi-device 'radio0'
>>> option type 'mac80211'
>>> option hwmode '11ng'
>>> option macaddr '28:c6:8e:bb:9a:47'
>>> option htmode 'HT20'
>>> list ht_capab 'SHORT-GI-40'
>>> list ht_capab 'TX-STBC'
>>> list ht_capab 'RX-STBC1'
>>> list ht_capab 'DSSS_CCK-40'
>>> option txpower '26'
>>> option country 'FR'
>>> option distance '15'
>>> option channel 'auto'
>
> I don't know anyone that has fiddled with distance to such an extent.
> your country codes need to be the same and you should look at what
> is allowed in FR.
>
>>> ======
>>>
>>> Some notes after having repaired the situation:
>>>
>>> - The pci paths to the radios was missing from /etc/config/wireless, that's the only thing that I saw that seemed grossly out of place.
>>>
>>> - Back up and running, and yes, it's much happier, now. Over wifi I get 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi has some ugly bufferbloat. (although these results are somewhat in question when the router has a 1m load average over 5.0...)
>
> Trying to measure the one way delay here is important (and hard. The
> only tool I've found for it so far was owamp, so I'm trying to write
> that test in twd). A TON of your delay is coming from your client. A
> network connection is like a fountain, or a toilet, both sides of the
> flow count...
>
>>>
>>> - Enabling all the SQM features I was having previously also considerably cleaned up wifi performance. It's more balanced, but still not nearly as balanced as I see on gigabit ethernet.
>>>
>>>
>>>
>>> -Aaron
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
[-- Attachment #2.1: Type: text/html, Size: 22525 bytes --]
[-- Attachment #2.2: tcp_bidirectional_hms-beagle_2_cerowrt.png --]
[-- Type: image/png, Size: 38902 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 22:56 ` Sebastian Moeller
@ 2014-01-16 23:12 ` Dave Taht
2014-01-16 23:25 ` Sebastian Moeller
0 siblings, 1 reply; 24+ messages in thread
From: Dave Taht @ 2014-01-16 23:12 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
[-- Attachment #1.1: Type: text/plain, Size: 14058 bytes --]
On Thu, Jan 16, 2014 at 5:56 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> many thanks for all the information & elucidation, as always.
>
I enjoy trying to find the words to explain.
>
> On Jan 16, 2014, at 23:30 , Dave Taht <dave.taht@gmail.com> wrote:
>
> On Thu, Jan 16, 2014 at 10:29 AM, Sebastian Moeller <moeller0@gmx.de>
> wrote:
>
> Hi Aaron,
>
> On Jan 16, 2014, at 16:03 , Aaron Wood <woody77@gmail.com> wrote:
>
> All,
>
> I'm noting this here in case anyone is interested. After I write this up,
> I'm going to start from scratch on the configuration, and factory-reset the
> router.
>
> =====
>
> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire
> sure what state it's in, but it seems to be only doing HT20 1x1. And in a
> fairly broken manner at that.
>
> Running the rrul test (over wifi directly to the router as the netserver),
> tcp uploads were 25Mbps or so, but download was 5Mbps.
>
>
> This is with your mac? Try rrul_noclassification, macosx (at least
> 10.8) will not do RRUL fair to a fast host. Why I do not know… it always
> prioritizes the upload, as if it did not see/trust the downstream markings
> (heck maybe it is busy using all bandwidth for upstream so that it
> literally never sees the markings on the downstream packets..)
>
>
> rrul with classification blows up 802.11e on all devices, everywhere.
> The VO and VI queues generally get all the bandwidth.
> Been saying that a while. VO and VI should be strictly admission
> controlled and are not, anywhere. All the queues fill
> and bad things happen. What should happen in a 802.11n world is that a
> set of packets should wind up in the best queue for the TXOP, and VO
> used not at all.
>
> rrul_noclassification better looks like the intent for classification
> was for 802.11e and thus works better. There are a couple
> other tests in the netperf-wrapper suite that don't use classification
> at all, that might be saner to use.
>
>
> Ah, so in rrul_noclassification, the UDP flows still are tos marked (at
> least that is reported in the plots and visible in the plots), but even
> using tcp_bidirectional I see a crazy imbalance 80:1, so this
> laptop's Broadcom BCM43xx (apple is not as informative as I would like
> about the components, but the firmware marker points at broadcom I would
> say) isn't better than the intel wifi in your's I would say…
>
the iwl is a nightmare. the 802.11ac stuff is looking bad too.
Another issue with the current implementation of rrul is my intent with the
specification was to test voip-like streams, an
isochronous 10ms packet in each direction.
The implementation currently sends measurement flows based on the RTT, just
like ping. As the RTT declines in length,
the amount of "space" used up by the measurement flow gets bigger and
bigger. At a 3ms RTT, just the EF measurement
flow eats ~2/3s of the available txops as it runs through the VO queue,
which is limited to a single packet per txop. The other measurement flows
like the CS5 flow, eat the VI queue, and the BE and BK queues get starved
for txops.
I can barely explain to myself how the queues are supposed to get airtime
scheduled, see the 802.11e page on wikipedia. I thought 802.11e was a bad
idea in the first place... but what rrul does is try to get txops on all 4
queues, which means it
needs 4x as much airtime (this is not accurate), and grabs airtime for it's
VO queue first most of the time, followed by
VI, BE, and bk.
I think for wifi testing with the current rrul test there needs to be a new
test that does everything in BE. (toke?)
Classification is very rarely used in the real world anyway.
Most of the usage of rrul to date has been over longer RTTs over
ethernet... (again, I'm delighted y'all are doing this,
and I do hope to get a more voip-like test)
>
>
>
> lastly, if you are doing a test over the internet, many providers pee
> on the tos bits. Unless you've done a packet capture, you can't trust
> that you are actually seeing classified packets coming back from the
> internet.
>
>
> Good point, comparing just the local rrul plots with the ones to demo, I
> see what you mean, there is a tiny bit of the priority classes visible in
> the uplink (bur barely) and none at all in the downlink, so my ISP does not
> think too much of the toe bits (I guess the tos effect on the uplink is
> from what cero is doing and since cero controls the bottleneck some
> "imprint" remains to be seen at packet reception time at demo, or so I
> think...).
>
simple.qos respects 3 of the 4 tiers that wifi does.
simplest does not.
>
>
> One of the things I hope to fix with the twd effort is to detect tos
> bit preservation and note it in the test.
>
>
> I'm delighted you'all are seeing these results for yourselves. Getting
> dinged on bandwidth after aiming for low latency by the public is not
> something I'd wanted to happen with a "stable" release. Regrettably
> fixing the drivers to work better only has
> felix working on it in his spare time, and I've been trying to clear
> my plate for months to help do the delicate rework
> required. (or recruit others to help)
>
>
> I would love to help, but this is far out of my league and area of
> expertise…
>
>
yer helping plenty, and the more people that "get this", the sooner people
will work
on fixing it. I have enjoyed trying to explain these behaviors today.
Someday
once we have words that match the concepts they will make sense to a CTO.
I have been very pleased by googling for bufferbloat of late. Almost
everyone that
has talked about it on the web for the past month seems to get it.
So if we start now, and make this the year of "make-wifi-fast", in a couple
years
maybe the world will get it...
... sadly long after 802.11ac is fully deployed and messing up everything
for
everybody.
> best
> Sebastian
>
>
>
> About the other issue I do not know anything…
>
> Best Regards
> Sebastian
>
> This is me 1-2 meters from the router. Load was never more than 0.33. (I
> can share the results of people are interested).
>
> After a full power cycle, wifi isn't coming up at all.
>
> =====
>
> How I got here:
>
>
> I'm in France, and had dutifully set my unit with the FR country code when
> setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms
> latency every 10-20 seconds over wifi) on the 5GHz network. The router was
> on channel 36, and I wanted to move it up to the far-upper ranges, so I
> tried to specify a "custom" channel to do so (140). This was the channel I
> thought I had been using with stock (Netgear) firmware.
>
> Wifi didn't come back up after applying the changes, and the luci
> interface seemed to be tripping up over stuff that it was reading out of
> the configuration files.
>
> I ssh'd in via ethernet, and fixed up the configurations by hand.
>
> Except the driver is still reporting that the 5GHz network won't kick into
> 802.11n modes, and won't use HT40. It seems to be sure it's configured for
> it, but isn't using it.
>
> Further, digging into the rc_stats files with the minstrel speeds, I found
> some very odd data (not what I was expecting to see:
>
> (laptop, which can do 2x2 HT40)
> rate throughput ewma prob this prob this succ/attempt success
> attempts
> D 6 6.0 99.9 100.0 2( 2) 65
> 65
> 9 0.0 0.0 0.0 0( 0) 0
> 0
> 12 2.9 25.0 100.0 0( 0) 1
> 1
> 18 4.3 25.0 100.0 0( 0) 1
> 1
> 24 5.6 25.0 100.0 0( 0) 1
> 1
> A P 36 32.4 99.9 100.0 0( 0) 51
> 51
> C 48 10.4 25.0 100.0 0( 0) 1
> 1
> B 54 11.5 25.0 100.0 0( 0) 1
> 1
>
> Total packet count:: ideal 53 lookaround 7
>
> (AppleTV, 1x1 HT20)
> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat
> stations/58\:55\:ca\:51\:b5\:4b/rc_stats
> rate throughput ewma prob this prob this succ/attempt success
> attempts
> 6 3.5 57.8 100.0 0( 0) 6
> 6
> 9 3.9 43.7 100.0 0( 0) 2
> 2
> 12 5.1 43.7 100.0 0( 0) 2
> 2
> 18 10.0 57.8 100.0 0( 0) 3
> 3
> D 24 13.1 57.8 100.0 0( 0) 3
> 3
> C 36 14.2 43.7 100.0 0( 0) 2
> 2
> B 48 18.2 43.7 100.0 0( 0) 2
> 2
> A P 54 46.2 99.9 100.0 1( 1) 348
> 367
>
>
> No AMPDUs. Hmm. Might be a bug.
>
> Total packet count:: ideal 331 lookaround 37
>
>
> Hmm. The radios are set for HT20 for the 2.4ghz and HT40+ for the
> 5ghz. I note that
> HT40 in wireless-n the 8 channels used up need to be congruent.
>
> HT40+ is 36+40, and 44+48 for example. You can't do 40+44.
>
> Availability of HTXX is dependent upon your regulatory domain.
>
> Whereas what I'm seeing for the 2.4GHz radio is:
>
> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat
> 10\:9a\:dd\:30\:96\:34/rc_stats
> type rate throughput ewma prob this prob retry this
> succ/attempt success attempts
> CCK/LP 1.0M 0.7 100.0 100.0 0
> 0( 0) 2 2
> CCK/SP 2.0M 0.0 0.0 0.0 0
> 0( 0) 0 0
> CCK/SP 5.5M 0.0 0.0 0.0 0
> 0( 0) 0 0
> CCK/SP 11.0M 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS0 5.6 100.0 100.0 1
> 0( 0) 2 2
> HT20/LGI MCS1 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS2 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS3 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS4 0.0 0.0 0.0 0
> 0( 0) 0 0
> HT20/LGI MCS5 30.3 100.0 100.0 5
> 0( 0) 1 1
> HT20/LGI t MCS6 32.5 100.0 100.0 5
> 0( 0) 11 11
> HT20/LGI T P MCS7 35.0 100.0 100.0 5
> 6( 6) 34 34
>
> Total packet count:: ideal 45 lookaround 3
> Average A-MPDU length: 1.3
>
>
> You are doing good at the highest possible rate. However packet
> aggregation is pretty terrible.
>
>
> And here are radio blocks from the current /etc/config/wireless:
>
> config wifi-device 'radio1'
> option type 'mac80211'
> option macaddr '28:c6:8e:bb:9a:49'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '17'
> option distance '25'
> option channel '48'
> option country 'US'
>
> config wifi-device 'radio0'
> option type 'mac80211'
> option hwmode '11ng'
> option macaddr '28:c6:8e:bb:9a:47'
> option htmode 'HT20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option txpower '26'
> option country 'FR'
> option distance '15'
> option channel 'auto'
>
>
> I don't know anyone that has fiddled with distance to such an extent.
> your country codes need to be the same and you should look at what
> is allowed in FR.
>
> ======
>
> Some notes after having repaired the situation:
>
> - The pci paths to the radios was missing from /etc/config/wireless,
> that's the only thing that I saw that seemed grossly out of place.
>
> - Back up and running, and yes, it's much happier, now. Over wifi I get
> 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi
> has some ugly bufferbloat. (although these results are somewhat in
> question when the router has a 1m load average over 5.0...)
>
>
> Trying to measure the one way delay here is important (and hard. The
> only tool I've found for it so far was owamp, so I'm trying to write
> that test in twd). A TON of your delay is coming from your client. A
> network connection is like a fountain, or a toilet, both sides of the
> flow count...
>
>
> - Enabling all the SQM features I was having previously also considerably
> cleaned up wifi performance. It's more balanced, but still not nearly as
> balanced as I see on gigabit ethernet.
>
>
>
> -Aaron
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>
>
>
--
Dave Täht
Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
[-- Attachment #1.2: Type: text/html, Size: 17635 bytes --]
[-- Attachment #2: tcp_bidirectional_hms-beagle_2_cerowrt.png --]
[-- Type: image/png, Size: 38902 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 22:50 ` Dave Taht
@ 2014-01-16 23:15 ` Sebastian Moeller
2014-01-16 23:40 ` Dave Taht
0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 23:15 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
Hi Dave,
thanks again.
On Jan 16, 2014, at 23:50 , Dave Taht <dave.taht@gmail.com> wrote:
>
>
>
> On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Aaron,
>
>
> On Jan 16, 2014, at 20:08 , Aaron Wood <woody77@gmail.com> wrote:
>
>>
>>>> Sebastian, after sorting out the router, it's still biased, but far
>>>> less
>>>> so, about a 2:1 ratio between upload and download.
>>>
>>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
>>
>> I get mixed results, but they aren't good.
>
> It's hard to comment on each graph in email, but I'll try.
>
> I generally run rrul with the --disable-log option. Log scales helped back when we were still
> comparing against pfifo fast.
Good point, I had not thought about this and just sheepishly copied the netperf-wrapper invocation from a scratch buffer…. oops.
>
> The really bad download graph. "Crazy results"
>
> Download bandwith is bad because the upload starts and fills the queue first, the download
> has to wait to fill the queue and generally gets dropped earlier than the upload. This is
> one of the many reasons I don't care for IW10….
But aren't those two different queues? I am confused...
>
> The upload gets better slowly due to how slow tcp is ramping up over the half-duplex
> wifi channel.
Yepp, my sentiment as well, the sharing between up and down sucks badly. I naively assumed that cero would sort of manage TX-ops and share these equally between its own sending needs and the remote station… I guess wifi is too complicated (and I had thought last mile wired connectivity was wonderfully weird...)
>
>
>
>
> I just checked again and I get crazy results for both RRUL and RRUL_NOCLASSIFICATION:
> <rrul_noclassification_macbook_2_cerowrt_5GHz.png><rrul_macbook_2_cerowrt_5GHz.png>
>
> in both cases I get ~ 10:1 out-in imbalance.
>
> I think that with a larger quantum on the AP they will be in less imbalance, and you should try nfq_codel also.
So for this I would modify the debloat script, correct?
>
> The larger quantum will also hurt, too.... right answer has always been per station queues.
Which I will happily test once they are implemented :)
>
>
> And even crazier just had one rrul where both in and out came up almost perfectly at 1:1
Thinking of it again, it might have been a case of really really low total bandwidth, so until this reoccurs I think it is a fluke...
>
>
> Hmm. Wifi is weird, isn't it? It's not like ethernet at all. Too bad the universe insists on trying to
> defy the laws of physics by trying to make it act like ethernet….
Oh, there was one new blurb last year about going full duplex on wifi, which might help to make wiki behave closer to what people nowadays correlate with ethernet...
>
>
> . Interestingly the classification really works in giving different bandwidth for the different classes. (And in rrul_noclassification, where the still classified UDP probes make it through the EF flow gets shorter latencies…).
>
> having 4 full queues and a txop each is far worse than 1 queue with better aggregation, IMHO.
So, the one queue would need to shave off all TOS (excuse my occasional shouting, but all caps is the quickest way to avoid auto correction turning my english even funnier), and have say HTB (or god forbid prio) keep some semblance of priority on the packets instead of letting wifi do its "let's waste a few tx ops" thing. Is it just me or should wifi basically get a better tx-ops sheduler?
>
>
> Note that measuring through cerowrt to a wired host (with too restrictive firewall settings) get:
> <rrul_macbook_2_cerowrt_2_happy-horse_5GHz.png><rrul_noclassification_macbook_2_cerowrt_2_happy-horse_5GHz.png>
>
> You are seeing the upload ramp up along tcp's lines and the download ramp down as it gets progressively more starved.
The sum seems constant, so yes.
>
>
> with the MacBooks uplink still dominant (actually continually getting more bandwidth…).
>
> Well, you only have X bandwidth, in the air, total. A better way of saying it might be the macbook is taking better advantage
> of it's txops to ship more data in an aggregate.
Mmh, it looks like it gets more tx-ops or cero gets increasingly bad in filling its tx-ops, no?
>
> Since I my only wireless connected machines are macs and nobody else complained about this issue I assume it is an osx issue
>
> I honestly think that aside from benchmarks, bandwidth is irrelevant on wifi. Lower latency is something that you
> actually feel, and when accessing the web or doing a videoconference, that's the part that matters.
Oh, sure, and my quick and dirty real world test (bidirectional data transfer initiated from the macbook turned out quite useable and balanced). And I only see this on the local net were wireless is the bottleneck. (Silly Idea, all I need to do is switch the wired machine to 10Mbit ethernet and I will be fine :) )
>
> it IS possible to get the best of both worlds, but that's going to take some driver rework.
>
>
> <PastedGraphic-2.tiff>
> For comparison an RRUL test from the wired linux host to cerowrt, where things look much better...
>
>
>
>> IIRC, apple really changed something about the media access in 10.8, I'll look into that. And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)
>
> Yeah, good question whether this is the same in all macosx versions? (Sonner or later I will switch to 10.9 and repeat the measurements…) The saving grace is that I usually either upload or download at home between my 2 computers so I rarely feel the full force of this unfortunate macosx behavior. Just checked using SMB to copy a file to the wired machine and from the wired machine at the same time, nicely splits the bandwidth evenly between up and download, so this might be netsurf related...
>
>
> Single threaded tests will generally work ok, which is why nobody before has complained... which is why rrul exists to beat up things like torrent-like ,web like videoconferencing-like and voip-like behaviors.
And beating up it does ;)
best regards
Sebastian
>
>>
>>
>>>> Also, my understanding was that with rts/cts, the router was in control
>>>> of
>>>> that aspect of things?
>>>
>>> That is what I thought AS well, but it is not what I See with osx 10.8.
>>>
>>
>> It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.
>
> I think we agree that the AP should show more self-confidence and reject such requests more firmly :)
>
>
>>
>> It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).
>
> I am not really equipped to do this, with just one wireless notebook at my disposal :)
>
> best
> Sebastian
>
>
> Now that you have your laptops running this stuff (AWESOME thank you!)
>
> If I can encourage you all to go outside, to like your nearest cybercafe, or conference center, and run your rrul tests there...
>
> ... you'll find out just how bad the rest of the world is... (and get some good data).
>
> I routinely see 4-6 seconds of latency, and a bare megabit or two of actual bandwidth. The ONLY place Iv'e ever had decent wifi performance in a busy area has been at ietf conferences....
>
>
>>
>> --Aaron
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 23:12 ` Dave Taht
@ 2014-01-16 23:25 ` Sebastian Moeller
0 siblings, 0 replies; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-16 23:25 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
Hi Dave,
On Jan 17, 2014, at 00:12 , Dave Taht <dave.taht@gmail.com> wrote:
>
>
>
> On Thu, Jan 16, 2014 at 5:56 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> many thanks for all the information & elucidation, as always.
>
> I enjoy trying to find the words to explain.
>
>
> On Jan 16, 2014, at 23:30 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Thu, Jan 16, 2014 at 10:29 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>> Hi Aaron,
>>>
>>> On Jan 16, 2014, at 16:03 , Aaron Wood <woody77@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> I'm noting this here in case anyone is interested. After I write this up, I'm going to start from scratch on the configuration, and factory-reset the router.
>>>>
>>>> =====
>>>>
>>>> The 5GHz radio on my 3800 seems to be in a very odd state. I'm not quire sure what state it's in, but it seems to be only doing HT20 1x1. And in a fairly broken manner at that.
>>>>
>>>> Running the rrul test (over wifi directly to the router as the netserver), tcp uploads were 25Mbps or so, but download was 5Mbps.
>>>
>>> This is with your mac? Try rrul_noclassification, macosx (at least 10.8) will not do RRUL fair to a fast host. Why I do not know… it always prioritizes the upload, as if it did not see/trust the downstream markings (heck maybe it is busy using all bandwidth for upstream so that it literally never sees the markings on the downstream packets..)
>>
>> rrul with classification blows up 802.11e on all devices, everywhere.
>> The VO and VI queues generally get all the bandwidth.
>> Been saying that a while. VO and VI should be strictly admission
>> controlled and are not, anywhere. All the queues fill
>> and bad things happen. What should happen in a 802.11n world is that a
>> set of packets should wind up in the best queue for the TXOP, and VO
>> used not at all.
>>
>> rrul_noclassification better looks like the intent for classification
>> was for 802.11e and thus works better. There are a couple
>> other tests in the netperf-wrapper suite that don't use classification
>> at all, that might be saner to use.
>
> Ah, so in rrul_noclassification, the UDP flows still are tos marked (at least that is reported in the plots and visible in the plots), but even using tcp_bidirectional I see a crazy imbalance 80:1, so this laptop's Broadcom BCM43xx (apple is not as informative as I would like about the components, but the firmware marker points at broadcom I would say) isn't better than the intel wifi in your's I would say…
>
> the iwl is a nightmare. the 802.11ac stuff is looking bad too.
>
> Another issue with the current implementation of rrul is my intent with the specification was to test voip-like streams, an
> isochronous 10ms packet in each direction.
>
> The implementation currently sends measurement flows based on the RTT, just like ping. As the RTT declines in length,
> the amount of "space" used up by the measurement flow gets bigger and bigger. At a 3ms RTT, just the EF measurement
> flow eats ~2/3s of the available txops as it runs through the VO queue, which is limited to a single packet per txop.
So, how much data could one fit into a txop? Would it make sense for the driver to "pad" the VO txop with other data just to efficiently use the air bottleneck?
> The other measurement flows like the CS5 flow, eat the VI queue, and the BE and BK queues get starved for tops.
Ah so this is why I only see the TOS UDP data in the rrul_noclassification test, as they are otherwise crowded out by the tcp streams of same class, and nbot reported after the first drop...
>
> I can barely explain to myself how the queues are supposed to get airtime scheduled, see the 802.11e page on wikipedia. I thought 802.11e was a bad idea in the first place... but what rrul does is try to get txops on all 4 queues, which means it
> needs 4x as much airtime (this is not accurate), and grabs airtime for it's VO queue first most of the time, followed by
> VI, BE, and bk.
>
> I think for wifi testing with the current rrul test there needs to be a new test that does everything in BE. (toke?)
> Classification is very rarely used in the real world anyway.
So that means the UDP streams as well?
>
> Most of the usage of rrul to date has been over longer RTTs over ethernet... (again, I'm delighted y'all are doing this,
> and I do hope to get a more voip-like test)
Yeah netperf-wrapper has been a delight in getting the ATM mess sorted out, great work. And now with the successor in the works things will get even better :)
>
>
> <tcp_bidirectional_hms-beagle_2_cerowrt.png>
>
>>
>> lastly, if you are doing a test over the internet, many providers pee
>> on the tos bits. Unless you've done a packet capture, you can't trust
>> that you are actually seeing classified packets coming back from the
>> internet.
>
> Good point, comparing just the local rrul plots with the ones to demo, I see what you mean, there is a tiny bit of the priority classes visible in the uplink (bur barely) and none at all in the downlink, so my ISP does not think too much of the toe bits (I guess the tos effect on the uplink is from what cero is doing and since cero controls the bottleneck some "imprint" remains to be seen at packet reception time at demo, or so I think...).
>
> simple.qos respects 3 of the 4 tiers that wifi does.
>
> simplest does not.
I know, even though I have no real use case I like the general idea of having dedicated bandwidth-limited channels for normal, important , and background traffic. Sort of just in case, belt and suspender kind of thinking.
>
>
>>
>> One of the things I hope to fix with the twd effort is to detect tos
>> bit preservation and note it in the test.
>>
>> I'm delighted you'all are seeing these results for yourselves. Getting
>> dinged on bandwidth after aiming for low latency by the public is not
>> something I'd wanted to happen with a "stable" release. Regrettably
>> fixing the drivers to work better only has
>> felix working on it in his spare time, and I've been trying to clear
>> my plate for months to help do the delicate rework
>> required. (or recruit others to help)
>
> I would love to help, but this is far out of my league and area of expertise…
>
>
> yer helping plenty, and the more people that "get this", the sooner people will work
> on fixing it. I have enjoyed trying to explain these behaviors today. Someday
> once we have words that match the concepts they will make sense to a CTO.
>
> I have been very pleased by googling for bufferbloat of late. Almost everyone that
> has talked about it on the web for the past month seems to get it.
>
> So if we start now, and make this the year of "make-wifi-fast", in a couple years
> maybe the world will get it...
>
> ... sadly long after 802.11ac is fully deployed and messing up everything for
> everybody.
"Make wifi fast" is a pretty good motto…
Best regards
Sebastian
> best
> Sebastian
>
>>
>>
>>> About the other issue I do not know anything…
>>>
>>> Best Regards
>>> Sebastian
>>>
>>>> This is me 1-2 meters from the router. Load was never more than 0.33. (I can share the results of people are interested).
>>>>
>>>> After a full power cycle, wifi isn't coming up at all.
>>>>
>>>> =====
>>>>
>>>> How I got here:
>>>>
>>>>
>>>> I'm in France, and had dutifully set my unit with the FR country code when setting up CeroWRT. I had noticed some odd latencies (periodic 100-200ms latency every 10-20 seconds over wifi) on the 5GHz network. The router was on channel 36, and I wanted to move it up to the far-upper ranges, so I tried to specify a "custom" channel to do so (140). This was the channel I thought I had been using with stock (Netgear) firmware.
>>>>
>>>> Wifi didn't come back up after applying the changes, and the luci interface seemed to be tripping up over stuff that it was reading out of the configuration files.
>>>>
>>>> I ssh'd in via ethernet, and fixed up the configurations by hand.
>>>>
>>>> Except the driver is still reporting that the 5GHz network won't kick into 802.11n modes, and won't use HT40. It seems to be sure it's configured for it, but isn't using it.
>>>>
>>>> Further, digging into the rc_stats files with the minstrel speeds, I found some very odd data (not what I was expecting to see:
>>>>
>>>> (laptop, which can do 2x2 HT40)
>>>> rate throughput ewma prob this prob this succ/attempt success attempts
>>>> D 6 6.0 99.9 100.0 2( 2) 65 65
>>>> 9 0.0 0.0 0.0 0( 0) 0 0
>>>> 12 2.9 25.0 100.0 0( 0) 1 1
>>>> 18 4.3 25.0 100.0 0( 0) 1 1
>>>> 24 5.6 25.0 100.0 0( 0) 1 1
>>>> A P 36 32.4 99.9 100.0 0( 0) 51 51
>>>> C 48 10.4 25.0 100.0 0( 0) 1 1
>>>> B 54 11.5 25.0 100.0 0( 0) 1 1
>>>>
>>>> Total packet count:: ideal 53 lookaround 7
>>>>
>>>> (AppleTV, 1x1 HT20)
>>>> root@cerowrt:/sys/kernel/debug/ieee80211/phy1/netdev:sw10# cat stations/58\:55\:ca\:51\:b5\:4b/rc_stats
>>>> rate throughput ewma prob this prob this succ/attempt success attempts
>>>> 6 3.5 57.8 100.0 0( 0) 6 6
>>>> 9 3.9 43.7 100.0 0( 0) 2 2
>>>> 12 5.1 43.7 100.0 0( 0) 2 2
>>>> 18 10.0 57.8 100.0 0( 0) 3 3
>>>> D 24 13.1 57.8 100.0 0( 0) 3 3
>>>> C 36 14.2 43.7 100.0 0( 0) 2 2
>>>> B 48 18.2 43.7 100.0 0( 0) 2 2
>>>> A P 54 46.2 99.9 100.0 1( 1) 348 367
>>>>
>>
>> No AMPDUs. Hmm. Might be a bug.
>>
>>>> Total packet count:: ideal 331 lookaround 37
>>
>> Hmm. The radios are set for HT20 for the 2.4ghz and HT40+ for the
>> 5ghz. I note that
>> HT40 in wireless-n the 8 channels used up need to be congruent.
>>
>> HT40+ is 36+40, and 44+48 for example. You can't do 40+44.
>>
>> Availability of HTXX is dependent upon your regulatory domain.
>>
>>>> Whereas what I'm seeing for the 2.4GHz radio is:
>>>>
>>>> root@cerowrt:/sys/kernel/debug/ieee80211/phy0/netdev:sw00/stations# cat 10\:9a\:dd\:30\:96\:34/rc_stats
>>>> type rate throughput ewma prob this prob retry this succ/attempt success attempts
>>>> CCK/LP 1.0M 0.7 100.0 100.0 0 0( 0) 2 2
>>>> CCK/SP 2.0M 0.0 0.0 0.0 0 0( 0) 0 0
>>>> CCK/SP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
>>>> CCK/SP 11.0M 0.0 0.0 0.0 0 0( 0) 0 0
>>>> HT20/LGI MCS0 5.6 100.0 100.0 1 0( 0) 2 2
>>>> HT20/LGI MCS1 0.0 0.0 0.0 0 0( 0) 0 0
>>>> HT20/LGI MCS2 0.0 0.0 0.0 0 0( 0) 0 0
>>>> HT20/LGI MCS3 0.0 0.0 0.0 0 0( 0) 0 0
>>>> HT20/LGI MCS4 0.0 0.0 0.0 0 0( 0) 0 0
>>>> HT20/LGI MCS5 30.3 100.0 100.0 5 0( 0) 1 1
>>>> HT20/LGI t MCS6 32.5 100.0 100.0 5 0( 0) 11 11
>>>> HT20/LGI T P MCS7 35.0 100.0 100.0 5 6( 6) 34 34
>>>>
>>>> Total packet count:: ideal 45 lookaround 3
>>>> Average A-MPDU length: 1.3
>>
>> You are doing good at the highest possible rate. However packet
>> aggregation is pretty terrible.
>>
>>>>
>>>> And here are radio blocks from the current /etc/config/wireless:
>>>>
>>>> config wifi-device 'radio1'
>>>> option type 'mac80211'
>>>> option macaddr '28:c6:8e:bb:9a:49'
>>>> list ht_capab 'SHORT-GI-40'
>>>> list ht_capab 'TX-STBC'
>>>> list ht_capab 'RX-STBC1'
>>>> list ht_capab 'DSSS_CCK-40'
>>>> option txpower '17'
>>>> option distance '25'
>>>> option channel '48'
>>>> option country 'US'
>>>>
>>>> config wifi-device 'radio0'
>>>> option type 'mac80211'
>>>> option hwmode '11ng'
>>>> option macaddr '28:c6:8e:bb:9a:47'
>>>> option htmode 'HT20'
>>>> list ht_capab 'SHORT-GI-40'
>>>> list ht_capab 'TX-STBC'
>>>> list ht_capab 'RX-STBC1'
>>>> list ht_capab 'DSSS_CCK-40'
>>>> option txpower '26'
>>>> option country 'FR'
>>>> option distance '15'
>>>> option channel 'auto'
>>
>> I don't know anyone that has fiddled with distance to such an extent.
>> your country codes need to be the same and you should look at what
>> is allowed in FR.
>>
>>>> ======
>>>>
>>>> Some notes after having repaired the situation:
>>>>
>>>> - The pci paths to the radios was missing from /etc/config/wireless, that's the only thing that I saw that seemed grossly out of place.
>>>>
>>>> - Back up and running, and yes, it's much happier, now. Over wifi I get 60-70Mbps upload and ~40Mbps download (running rrul). Latency sucks. Wifi has some ugly bufferbloat. (although these results are somewhat in question when the router has a 1m load average over 5.0...)
>>
>> Trying to measure the one way delay here is important (and hard. The
>> only tool I've found for it so far was owamp, so I'm trying to write
>> that test in twd). A TON of your delay is coming from your client. A
>> network connection is like a fountain, or a toilet, both sides of the
>> flow count...
>>
>>>>
>>>> - Enabling all the SQM features I was having previously also considerably cleaned up wifi performance. It's more balanced, but still not nearly as balanced as I see on gigabit ethernet.
>>>>
>>>>
>>>>
>>>> -Aaron
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 23:15 ` Sebastian Moeller
@ 2014-01-16 23:40 ` Dave Taht
2014-01-17 20:15 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 24+ messages in thread
From: Dave Taht @ 2014-01-16 23:40 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
On Thu, Jan 16, 2014 at 6:15 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> thanks again.
>
> On Jan 16, 2014, at 23:50 , Dave Taht <dave.taht@gmail.com> wrote:
>
>>
>>
>>
>> On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Aaron,
>>
>>
>> On Jan 16, 2014, at 20:08 , Aaron Wood <woody77@gmail.com> wrote:
>>
>>>
>>>>> Sebastian, after sorting out the router, it's still biased, but far
>>>>> less
>>>>> so, about a 2:1 ratio between upload and download.
>>>>
>>>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate
>>>
>>> I get mixed results, but they aren't good.
>>
>> It's hard to comment on each graph in email, but I'll try.
>>
>> I generally run rrul with the --disable-log option. Log scales helped back when we were still
>> comparing against pfifo fast.
>
> Good point, I had not thought about this and just sheepishly copied the netperf-wrapper invocation from a scratch buffer…. oops.
I think --disable-log should be the default... except that for
everyone not running an AQM the results they will get
will need log scales...
>
>>
>> The really bad download graph. "Crazy results"
>>
>> Download bandwith is bad because the upload starts and fills the queue first, the download
>> has to wait to fill the queue and generally gets dropped earlier than the upload. This is
>> one of the many reasons I don't care for IW10….
>
> But aren't those two different queues? I am confused...
One flow using TCP is sending 66 byte acks at the same time another
flow is sending full 1500 byte packets.
so if you have "2" TCP flows, you actually have 4 flows, 2 in each
direction, one with big packets, the other with
little.
So what is happening in the fq_codel case with a 300 byte quantum is
you will see (flows 1 and 3 are down,
2 and 4 are data up), roughly, in a packet capture, is something like this:
FLOW ACK DATA
1 1
1 1
1 1
1 1
2 1
3 1
3 1
3 1
3 1
4 1
1 1
1 1
1 1
1 1
3 1
3 1
3 1
3 1
1 1
1 1
1 1
1 1
3 1
3 1
3 1
3 1 (repeat til you've served up 1500 bytes from each
small flow, then deliver the 1500 byte packet)
It's more complicated than this as you typically ack only every other packet...
nfq_codel is different in that it rotates the flow queue on every
packet much like SFQ does, but still pays
attention to the quantum
1 1
2 1
3 1
4 1
1 1
3 1
1 1
3 1
1 1
1 1 # serve up 1500 bytes of acks
2 1
4 1
SFQ would look like this
1 1
2 1
3 1
4 1
1 1
2 1
3 1
4 1
I've long meant to port over the sfq_codel implementation from ns2 but haven't
got round to it.
>> The upload gets better slowly due to how slow tcp is ramping up over the half-duplex
>> wifi channel.
>
> Yepp, my sentiment as well, the sharing between up and down sucks badly. I naively assumed that cero would sort of manage TX-ops and share these equally between its own sending needs and the remote station… I guess wifi is too complicated (and I had thought last mile wired connectivity was wonderfully weird...)
One day... I view most of the problems modern-day wifi has as
solvable... and critical to society that we fix them.
>
>>
>>
>>
>>
>> I just checked again and I get crazy results for both RRUL and RRUL_NOCLASSIFICATION:
>> <rrul_noclassification_macbook_2_cerowrt_5GHz.png><rrul_macbook_2_cerowrt_5GHz.png>
>>
>> in both cases I get ~ 10:1 out-in imbalance.
>>
>> I think that with a larger quantum on the AP they will be in less imbalance, and you should try nfq_codel also.
>
> So for this I would modify the debloat script, correct?
look at the nfq_codel_ll definitions in the file.
There is an SFQ model in there too that might be interesting to try.
the big problem is that no matter how much we twiddle up at this level
there is still far too much queuing in the
driver itself to see much effect (unless you hold the qlen vars at the
levels they are at now)
Ideally all the fq and aqm stuff happens *just before* an aggregate
gets created.
>>
>> The larger quantum will also hurt, too.... right answer has always been per station queues.
>
> Which I will happily test once they are implemented :)
been 3 years since we started discussing it and looking for funding.
>
>>
>>
>> And even crazier just had one rrul where both in and out came up almost perfectly at 1:1
>
> Thinking of it again, it might have been a case of really really low total bandwidth, so until this reoccurs I think it is a fluke...
>
>>
>>
>> Hmm. Wifi is weird, isn't it? It's not like ethernet at all. Too bad the universe insists on trying to
>> defy the laws of physics by trying to make it act like ethernet….
>
> Oh, there was one new blurb last year about going full duplex on wifi, which might help to make wiki behave closer to what people nowadays correlate with ethernet...
>
>>
>>
>> . Interestingly the classification really works in giving different bandwidth for the different classes. (And in rrul_noclassification, where the still classified UDP probes make it through the EF flow gets shorter latencies…).
>>
>> having 4 full queues and a txop each is far worse than 1 queue with better aggregation, IMHO.
>
> So, the one queue would need to shave off all TOS (excuse my occasional shouting, but all caps is the quickest way to avoid auto correction turning my english even funnier), and have say HTB (or god forbid prio) keep some semblance of priority on the packets instead of letting wifi do its "let's waste a few tx ops" thing. Is it just me or should wifi basically get a better tx-ops sheduler?
>
>>
>>
>> Note that measuring through cerowrt to a wired host (with too restrictive firewall settings) get:
>> <rrul_macbook_2_cerowrt_2_happy-horse_5GHz.png><rrul_noclassification_macbook_2_cerowrt_2_happy-horse_5GHz.png>
>>
>> You are seeing the upload ramp up along tcp's lines and the download ramp down as it gets progressively more starved.
>
> The sum seems constant, so yes.
>
>
>>
>>
>> with the MacBooks uplink still dominant (actually continually getting more bandwidth…).
>>
>> Well, you only have X bandwidth, in the air, total. A better way of saying it might be the macbook is taking better advantage
>> of it's txops to ship more data in an aggregate.
>
> Mmh, it looks like it gets more tx-ops or cero gets increasingly bad in filling its tx-ops, no?
>
>>
>> Since I my only wireless connected machines are macs and nobody else complained about this issue I assume it is an osx issue
>>
>> I honestly think that aside from benchmarks, bandwidth is irrelevant on wifi. Lower latency is something that you
>> actually feel, and when accessing the web or doing a videoconference, that's the part that matters.
>
> Oh, sure, and my quick and dirty real world test (bidirectional data transfer initiated from the macbook turned out quite useable and balanced). And I only see this on the local net were wireless is the bottleneck. (Silly Idea, all I need to do is switch the wired machine to 10Mbit ethernet and I will be fine :) )
>
>
>>
>> it IS possible to get the best of both worlds, but that's going to take some driver rework.
>>
>>
>> <PastedGraphic-2.tiff>
>> For comparison an RRUL test from the wired linux host to cerowrt, where things look much better...
>>
>>
>>
>>> IIRC, apple really changed something about the media access in 10.8, I'll look into that. And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)
>>
>> Yeah, good question whether this is the same in all macosx versions? (Sonner or later I will switch to 10.9 and repeat the measurements…) The saving grace is that I usually either upload or download at home between my 2 computers so I rarely feel the full force of this unfortunate macosx behavior. Just checked using SMB to copy a file to the wired machine and from the wired machine at the same time, nicely splits the bandwidth evenly between up and download, so this might be netsurf related...
>>
>>
>> Single threaded tests will generally work ok, which is why nobody before has complained... which is why rrul exists to beat up things like torrent-like ,web like videoconferencing-like and voip-like behaviors.
>
> And beating up it does ;)
>
> best regards
> Sebastian
>
>
>
>>
>>>
>>>
>>>>> Also, my understanding was that with rts/cts, the router was in control
>>>>> of
>>>>> that aspect of things?
>>>>
>>>> That is what I thought AS well, but it is not what I See with osx 10.8.
>>>>
>>>
>>> It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.
>>
>> I think we agree that the AP should show more self-confidence and reject such requests more firmly :)
>>
>>
>>>
>>> It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).
>>
>> I am not really equipped to do this, with just one wireless notebook at my disposal :)
>>
>> best
>> Sebastian
>>
>>
>> Now that you have your laptops running this stuff (AWESOME thank you!)
>>
>> If I can encourage you all to go outside, to like your nearest cybercafe, or conference center, and run your rrul tests there...
>>
>> ... you'll find out just how bad the rest of the world is... (and get some good data).
>>
>> I routinely see 4-6 seconds of latency, and a bare megabit or two of actual bandwidth. The ONLY place Iv'e ever had decent wifi performance in a busy area has been at ietf conferences....
>>
>>
>>>
>>> --Aaron
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-16 23:40 ` Dave Taht
@ 2014-01-17 20:15 ` Toke Høiland-Jørgensen
2014-01-17 20:17 ` Dave Taht
0 siblings, 1 reply; 24+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-01-17 20:15 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Dave Taht <dave.taht@gmail.com> writes:
> I think --disable-log should be the default... except that for
> everyone not running an AQM the results they will get will need log
> scales...
Actually, it currently does this:
if top_percentile/btm_percentile > 20.0 and settings.LOG_SCALE:
axis.set_yscale('log')
in an attempt to automatically do the right thing. Maybe it should be a
wider interval before turning on log scales?
I'll add an rrul_wifi test that makes everything BE.
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-17 20:15 ` Toke Høiland-Jørgensen
@ 2014-01-17 20:17 ` Dave Taht
2014-01-19 19:01 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 24+ messages in thread
From: Dave Taht @ 2014-01-17 20:17 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
On Fri, Jan 17, 2014 at 3:15 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> I think --disable-log should be the default... except that for
>> everyone not running an AQM the results they will get will need log
>> scales...
>
> Actually, it currently does this:
>
> if top_percentile/btm_percentile > 20.0 and settings.LOG_SCALE:
> axis.set_yscale('log')
>
> in an attempt to automatically do the right thing. Maybe it should be a
> wider interval before turning on log scales?
>
>
> I'll add an rrul_wifi test that makes everything BE.
hah. Calling it that is the opposite of my intent with default blow-up
of 802.11e - which has been to convince everyone it's busted and to
fix it.
rrul_be ?
>
> -Toke
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-17 20:17 ` Dave Taht
@ 2014-01-19 19:01 ` Toke Høiland-Jørgensen
2014-01-19 20:01 ` Sebastian Moeller
0 siblings, 1 reply; 24+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-01-19 19:01 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
Dave Taht <dave.taht@gmail.com> writes:
> hah. Calling it that is the opposite of my intent with default blow-up
> of 802.11e - which has been to convince everyone it's busted and to
> fix it.
>
> rrul_be ?
Added an rrul_be test to netperf-wrapper git. Will do a new release
version once I've fixed one or two other things. :)
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-19 19:01 ` Toke Høiland-Jørgensen
@ 2014-01-19 20:01 ` Sebastian Moeller
2014-01-19 20:58 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-19 20:01 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
Hi Toke,
On Jan 19, 2014, at 20:01 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> hah. Calling it that is the opposite of my intent with default blow-up
>> of 802.11e - which has been to convince everyone it's busted and to
>> fix it.
>>
>> rrul_be ?
>
> Added an rrul_be test to netperf-wrapper git. Will do a new release
> version once I've fixed one or two other things. :)
Great! just pull the repository.
I noticed the new "hostnames are mandatory police" kick in:
bash-3.2$ ./netperf-wrapper --list-tests
Available tests:
cisco_5tcpup : RTT Fair Realtime Response Under Load
cisco_5tcpup_2udpflood : Cisco 5TCP up + 2 6Mbit UDP
Error occurred: No hostname specified.
Maybe you could allow listing the tests without a hostname?
Anyway., just ran the rrul_be test from my macbook to cerowrt and I still see the massive bias for upload of around 10:1, same as with rrul and rrul_coclassification, and tcp_bidirectional. When I ran tcp_bidirectional on the universities wireless network (the only test that actually runs there), I get larger downloads than uploads. Wireless is weird...
Best
Sebastian
>
> -Toke
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-19 20:01 ` Sebastian Moeller
@ 2014-01-19 20:58 ` Toke Høiland-Jørgensen
2014-01-19 21:12 ` Sebastian Moeller
0 siblings, 1 reply; 24+ messages in thread
From: Toke Høiland-Jørgensen @ 2014-01-19 20:58 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
Sebastian Moeller <moeller0@gmx.de> writes:
> I noticed the new "hostnames are mandatory police" kick in:
Right, botched that; should be fixed properly now.
> Wireless is weird...
Yes, wayy too much black magic involved...
-Toke
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800)
2014-01-19 20:58 ` Toke Høiland-Jørgensen
@ 2014-01-19 21:12 ` Sebastian Moeller
0 siblings, 0 replies; 24+ messages in thread
From: Sebastian Moeller @ 2014-01-19 21:12 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
Hi Toke,
On Jan 19, 2014, at 21:58 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Sebastian Moeller <moeller0@gmx.de> writes:
>
>> I noticed the new "hostnames are mandatory police" kick in:
>
> Right, botched that; should be fixed properly now.
That was fast, and:
bash-3.2$ ./netperf-wrapper --list-tests
Available tests:
cisco_5tcpup : RTT Fair Realtime Response Under Load
cisco_5tcpup_2udpflood : Cisco 5TCP up + 2 6Mbit UDP
cubic_ledbat_1 : Cubic vs LEDBAT upload streams w/ping
ledbat_cubic_1 : Cubic vs LEDBAT upload streams w/ping
ping : Straight ping test
reno_cubic_westwood_ledbat : Realtime Response Under Load
(with different congestion control algs)
reno_cubic_westwood_lp : Realtime Response Under Load
(with different congestion control algs)
rrul : Realtime Response Under Load
rrul46 : Realtime Response Under Load - Mixed IPv4/6
rrul46compete : Realtime Response Under Load - Mixed v4/v6 compete
rrul_be : Realtime Response Under Load - exclusively Best Effort
rrul_noclassification : Realtime Response Under Load - no classification on data flows
rtt_fair : RTT Fair Realtime Response Under Load
rtt_fair4be : RTT Fair Realtime Response Under Load
rtt_fair6be : RTT Fair Realtime Response Under Load
tcp_1down : Bidirectional TCP streams w/ping
tcp_1up : Single TCP upload stream w/ping
tcp_bidirectional : Bidirectional TCP streams w/ping
tcp_download : TCP download stream w/ping
tcp_upload : TCP upload stream w/ping
udp_flood : UDP flood w/ping
bash-3.2$
Thanks a lot.
>
>> Wireless is weird...
>
> Yes, wayy too much black magic involved…
What I failed to mention, testing against demo (~32ms unloaded ping RTT) from home gives ping RTT around 50ms, from the university 200ms (both with tcp_bidirectional). Ouch, and this with a massive rsync job running at home on a wired machine(over the atlantic, so sharing resources with tcp_bidirectional).
Dave, you are right default wireless performance truly is suboptimal…
best
Sebastian
>
> -Toke
[-- Attachment #2.1: Type: text/html, Size: 4887 bytes --]
[-- Attachment #2.2: tcp_bidirectional_EKUT.png --]
[-- Type: image/png, Size: 47722 bytes --]
[-- Attachment #2.3: tcp_bidirectional_HOME2DEMO.png --]
[-- Type: image/png, Size: 51837 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-01-19 21:12 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-16 15:03 [Cerowrt-devel] Managed to break 802.11n (on a 3800) Aaron Wood
2014-01-16 15:29 ` Sebastian Moeller
2014-01-16 15:46 ` Aaron Wood
2014-01-16 17:20 ` Sebastian Moeller
2014-01-16 19:08 ` Aaron Wood
2014-01-16 20:10 ` Sebastian Moeller
2014-01-16 21:33 ` Aaron Wood
2014-01-16 22:50 ` Dave Taht
2014-01-16 23:15 ` Sebastian Moeller
2014-01-16 23:40 ` Dave Taht
2014-01-17 20:15 ` Toke Høiland-Jørgensen
2014-01-17 20:17 ` Dave Taht
2014-01-19 19:01 ` Toke Høiland-Jørgensen
2014-01-19 20:01 ` Sebastian Moeller
2014-01-19 20:58 ` Toke Høiland-Jørgensen
2014-01-19 21:12 ` Sebastian Moeller
2014-01-16 22:35 ` Dave Taht
2014-01-16 22:30 ` Dave Taht
2014-01-16 22:56 ` Sebastian Moeller
2014-01-16 23:12 ` Dave Taht
2014-01-16 23:25 ` Sebastian Moeller
2014-01-16 15:38 ` Robert Bradley
2014-01-16 15:46 ` Aaron Wood
2014-01-16 22:08 ` Dave Taht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox