[ath9k-devel] Zyxel NWD-170n badly slow

[Andrej Podzimek <andrej@podzimek.org>]

> ieee80211_regdom is the same thing as using 'iw reg set' but we will
> eventually remove ieee80211_regdom module parameter. Please consider
> abandoning it.

I removed the option from modprobe.conf. The initialization looks very similar. This appears instead of the CZ regdomain:

	cfg80211: World regulatory domain updated:                                                                        
	        (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)                                         
	        (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)                                              
	        (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)                                              
	        (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)                                              
	        (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)                                              
	        (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)                                              

However, two problems appeared:
	
	* spurious disconnections
		No probe response from AP 00:23:f8:22:aa:a6 after 200ms, disconnecting.

	* the card won't associate unless I set this manually:
		iw dev wlan0 set channel 6 HT40-

> Using what? iperf? TCP or UDP?

This is a *good* question! Yes, iperf. I didn't consider trying UDP before. The results are surprising, to say the least.

	TCP: 58 to 63 Mb/s
	UDP: 1 Mb/s

This was measured during a transfer that took 30 seconds. I tried both IPv4 and IPv6. (Presumably, results were almost the same.)

The UDP problem does not seem to be caused by packet loss:

	[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
	[  3]  0.0-30.0 sec  3.74 MBytes  1.05 Mbits/sec  0.777 ms    5/ 2675 (0.19%)
	[  3]  0.0-30.0 sec  1 datagrams received out-of-order

> I was under the impression 802.11n *requires QoS*, not sure why it
> would let you disable it..

Disabling QoS and enabling 40 MHz channels reduces the performance of 802.11g to about 10 Mb/s and the 802.11n adapter performs no better. When 40 MHz channels are disabled, 802.11g devices work normally (24 Mb/s) without QoS, but 802.11n devices only work at g speeds.

Simply put, disabling QoS probably disables 802.11n as well, although the web interface says it's enabled.

> Are you using 2.4 GHz or 5 GHz? What channel/freq are you on? How many
> APs can you detect nearby and what channels are they on? Try to set
> your AP to a channel far away from the others.

2.4 GHz.

There are mostly 3 visible APs on channels 1, 7 and 11. (Yes, that's quite a bad situation.) When I set automatic channel selection on the router, it sticks to channel 6. (I have never seen an automatic channel change.) All those visible APs are quite far away, below -75 dBm.

I also tried channels 4 and 13 with the client set to HT+ and HT- respectively, but the speed was about 80% of what I would get with the default channel 6. (I didn't measure this in detail, just a standard 10s test.) (UDP was a disaster again.)

> You should be able to do better than what you have. I'm not going to
> defend 11n but you should realize IEEE-802.11n is being standardized,
> Atheros turbo, or+ or whatever is not and will never get supported in
> ath9k, and very likely also not in ath5k.

This is *good* news.
(G+ is not supported.) && (Bandwidth exceeds 54 Mb/s.) => (802.11n works somehow.)

> You can check the ath9k rcstat:
> 
> http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
> 
> Please provide the output of that file after a few quick tests. Reset
> the counters by reloading ath9k if you want to compare against some
> different environment.

Thanks for the info. I'll definitely try this tomorrow.

> I have stuffed all pending patches into one file:
> 
> http://bombadil.infradead.org/~mcgrof/patches/all.patch
> 
> if you want to test using wireless-testing directly. Not sure if this
> will apply to compat-wireless cleanly.

Yes, it will. Nothing rejected. I'm compiling that now and will report results.

BTW, I ran into this weird error when watching the data rate and signal quality with ksysguard:

	BUG: scheduling while atomic: ksysguardd/6116/0x00000002
	Modules linked in: aes_i586 aes_generic ath9k mac80211 ath cfg80211 rfkill_backport arc4 ecb ipv6 sco bnep l2cap bluetooth rng_core uinput ohci1394 ieee1394 tun usbhid dvb_usb_af9015 dvb_usb dvb_core ipw2200 libipw lib80211 8139too mii lp ppdev parport_pc parport uhci_hcd ohci_hcd ehci_hcd usbcore pcspkr snd_intel8x0m snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_intel8x0 snd_ac97_codec snd_mixer_oss ac97_bus snd_pcm snd_page_alloc snd_rtctimer snd_timer snd soundcore rtc psmouse nsc_ircc irda crc_ccitt cpufreq_ondemand evdev pcmcia yenta_socket rsrc_nonstatic pcmcia_core asus_laptop speedstep_centrino freq_table lm90 hwmon i2c_i801 [last unloaded: rfkill_backport]
	Pid: 6116, comm: ksysguardd Not tainted 2.6.30.1-AP #3
	Call Trace:
	[<c03cae45>] ? __schedule+0x385/0x3a0
	[<c03cb84c>] ? __mutex_lock_slowpath+0x6c/0xf0
	[<c03cb769>] ? mutex_lock+0x9/0x10
	[<f0a9b1d9>] ? cfg80211_wireless_stats+0x69/0x160 [cfg80211]
	[<c03c2bff>] ? wireless_seq_show+0x3f/0x180
	[<c0195c92>] ? seq_read+0x242/0x3d0
	[<c0195a50>] ? seq_read+0x0/0x3d0
	[<c01b7920>] ? proc_reg_read+0x0/0xb0
	[<c01b7976>] ? proc_reg_read+0x56/0xb0
	[<c017d805>] ? vfs_read+0xa5/0x150
	[<c017b030>] ? do_sys_open+0xc0/0xf0
	[<c017d971>] ? sys_read+0x41/0x70
	[<c0102df4>] ? sysenter_do_call+0x12/0x26

This seems to have nothing in common with ath9k... It probably happens when a process uses the old wireless configuration API. It sometimes happens to iwconfig as well. Should I report this to the kernel bugzilla? All works fine with iw, so this may be related to some deprecated code.

Andrej