From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrej Podzimek Date: Sat, 18 Jul 2009 01:42:20 +0200 Subject: [ath9k-devel] Zyxel NWD-170n badly slow In-Reply-To: <43e72e890907171424i66afc975k9fc25687dacb383@mail.gmail.com> References: <4A60A0EF.5050601@podzimek.org> <43e72e890907170930u5205c1c0g50ee27cd119349c5@mail.gmail.com> <4A60B561.30205@podzimek.org> <43e72e890907171059kfec2366qf7d8d8b50f67d575@mail.gmail.com> <4A60E50C.5020000@podzimek.org> <43e72e890907171424i66afc975k9fc25687dacb383@mail.gmail.com> Message-ID: <4A610C5C.1040102@podzimek.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.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: [] ? __schedule+0x385/0x3a0 [] ? __mutex_lock_slowpath+0x6c/0xf0 [] ? mutex_lock+0x9/0x10 [] ? cfg80211_wireless_stats+0x69/0x160 [cfg80211] [] ? wireless_seq_show+0x3f/0x180 [] ? seq_read+0x242/0x3d0 [] ? seq_read+0x0/0x3d0 [] ? proc_reg_read+0x0/0xb0 [] ? proc_reg_read+0x56/0xb0 [] ? vfs_read+0xa5/0x150 [] ? do_sys_open+0xc0/0xf0 [] ? sys_read+0x41/0x70 [] ? 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