Now at home I have had some performance issues. With a signal between -40 to -50 dBm and link quality 65-70/70 I get ~3 Mbps with an iperf test with my home server. I do not have any object between the AP and the computer itself. Another time the number of "Invalid misc" packets increases a lot when there are some traffic. It is possible that this is related with a configuration problem? I have recorded 2 videos to show the increase of invalid packets. I will try to edit them to remove info like mac address and I upload them. (Any service that you can recommend me?) Thanks a lot again for your help. David 2013/12/5 David Pinilla Caparrós <dpini@xxxxxxxxx>: > 2013/12/5 Larry Finger <Larry.Finger@xxxxxxxxxxxx>: >> On 12/04/2013 05:08 PM, David Pinilla Caparrós wrote: >>> >>> 2013/12/4 Larry Finger <Larry.Finger@xxxxxxxxxxxx>: >>>> >>>> On 12/04/2013 03:40 PM, David Pinilla Caparrós wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> I have mailed with Larry Finger asking for a problem and he has >>>>> pointed me to this list. >>>>> >>>>> I am an Arch Linux User with a Clevo based laptop. >>>>> >>>>> It ships with the RTL8723AE. I have been reading posts around the net >>>>> and found that some people are having problems and talking about the >>>>> driver and something about the RX or TX Power. >>>>> >>>>> >>>>> With the 2 APs wich I usually use I can only reach 18Mb/s of Bit rate >>>>> whatever the signal level or link quality is. Both of them are 802.11 >>>>> G and not N I think. >>>>> >>>>> The connection is very unstable. Sometimes powering the wifi off and >>>>> on increases the performance a bit when it's impossible to do anything >>>>> (pings to gateway don't reply) >>>>> >>>>> If they are related to the driver, I would be proud to help with >>>>> anything that I am able to. Testing for example. >>>>> >>>>> I have a recent version of the stable Kernel but I dont know if the >>>>> firmware files are up to date. >>>>> >>>>> >>>>> >>>>> Some data: >>>>> >>>>> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723AE >>>>> PCIe Wireless Network Adapter >>>>> Subsystem: Realtek Semiconductor Co., Ltd. Device 0726 >>>>> Flags: bus master, fast devsel, latency 0, IRQ 18 >>>>> I/O ports at d000 [size=256] >>>>> Memory at f7900000 (64-bit, non-prefetchable) [size=16K] >>>>> Capabilities: [40] Power Management version 3 >>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ >>>>> Capabilities: [70] Express Endpoint, MSI 00 >>>>> Capabilities: [100] Advanced Error Reporting >>>>> Capabilities: [140] Virtual Channel >>>>> Capabilities: [160] Device Serial Number 01-23-87-fe-ff-4c-e0-00 >>>>> Kernel driver in use: rtl8723ae >>>>> Kernel modules: rtl8723ae >>>>> >>>>> root ~ dmesg | grep rtl >>>>> [ 2.734124] rtl8723ae 0000:03:00.0: enabling device (0000 -> 0003) >>>>> [ 2.749732] rtl8723ae: Using firmware rtlwifi/rtl8723fw_B.bin >>>>> [ 2.752940] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' >>>>> [ 2.753057] rtlwifi: wireless switch is on >>>>> [ 8838.570486] rtlwifi: wireless switch is o >>>>> >>>>> >>>>> root ~ uname -a >>>>> Linux DPini-Laptop 3.12.2-1-ARCH #1 SMP PREEMPT Fri Nov 29 21:14:15 >>>>> CET 2013 x86_64 GNU/Linux >>>>> >>>>> >>>>> Iwconfig: >>>>> >>>>> wlp3s0 IEEE 802.11bgn ESSID:"Pinis_AP" >>>>> Mode:Managed Frequency:2.462 GHz Access Point: >>>>> 00:1A:2B:12:34:56 >>>>> Bit Rate=18 Mb/s Tx-Power=20 dBm >>>>> Retry long limit:7 RTS thr=2347 B Fragment thr:off >>>>> Encryption key:off >>>>> Power Management:off >>>>> Link Quality=50/70 Signal level=-60 dBm >>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 >>>>> Tx excessive retries:0 Invalid misc:9 Missed beacon:0 >>>>> >>>>> root ~ rfkill list >>>>> 0: phy0: Wireless LAN >>>>> Soft blocked: no >>>>> Hard blocked: no >>>>> 1: hci0: Bluetooth >>>>> Soft blocked: no >>>>> Hard blocked: no >>>>> >>>>> root ⋯ lib firmware rtlwifi md5sum rtl8723fw* >>>>> ce50dfe07dbb1bfe9e14bdb315a4b28a rtl8723fw_B.bin >>>>> 69ccaffbe94cc0ef1b89c25290e19b2e rtl8723fw.bin >>>> >>>> >>> >>> Inline reply >>> >>>> Those md5sums match those of the latest firmware. >>> >>> >>> Thanks. It's a great notice >>> >>>> Your signal is a bit lower than mine. My iwconfig shows >>>> >>>> wlp14s0 IEEE 802.11bgn ESSID:"NETGEAR81" >>>> Mode:Managed Frequency:2.437 GHz Access Point: >>>> 20:E5:2A:01:F7:EA >>>> Bit Rate=7.2 Mb/s Tx-Power=20 dBm >>>> >>>> Retry long limit:7 RTS thr=2347 B Fragment thr:off >>>> Power Management:off >>>> Link Quality=60/70 Signal level=-50 dBm >>>> >>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 >>>> Tx excessive retries:0 Invalid misc:2254 Missed beacon:0 >>>> >>>> My AP is 802.11n. Note that the 7.2 Mbps is misleading. When I pushed >>>> data >>>> through using netperf, it jumped to 72.2 Mbps, and my throughput was >>>> >>>> TCP_MAERTS Test: 30.64 27.65 30.54 28.86 33.33 33.59 37.86 39.40 39.76 >>>> 37.20 >>>> RX Results: max 39.76, min 27.65. Mean 33.88(4.22) >>>> >>>> TCP_STREAM Test: 35.34 37.34 29.59 20.10 36.11 40.24 40.67 41.93 38.08 >>>> 33.93 >>>> TX Results: max 41.93, min 20.10. Mean 35.33(6.13) >>>> >>>> When I switch to an 802.11g AP, I get the following: >>>> >>>> TCP_MAERTS Test: 10.77 10.81 11.53 11.69 10.46 10.16 11.04 10.66 7.34 >>>> 10.90 >>>> RX Results: max 11.69, min 7.34. Mean 10.54(1.15) >>>> >>>> TCP_STREAM Test: 5.74 6.24 6.76 6.43 7.37 6.23 7.63 7.07 7.07 >>>> 6.50 >>>> TX Results: max 7.63, min 5.74. Mean 6.70(0.55) >>> >>> >>> Here at home I get similar results: >>> >>> dpini ~ iperf -c 192.168.1.102 >>> ------------------------------------------------------------ >>> Client connecting to 192.168.1.102, TCP port 5001 >>> TCP window size: 22.9 KByte (default) >>> ------------------------------------------------------------ >>> [ 3] local 192.168.1.117 port 36449 connected with 192.168.1.102 port >>> 5001 >>> [ ID] Interval Transfer Bandwidth >>> [ 3] 0.0-10.3 sec 10.0 MBytes 8.13 Mbits/sec >>> dpini ~ iperf -c 192.168.1.102 >>> ------------------------------------------------------------ >>> Client connecting to 192.168.1.102, TCP port 5001 >>> TCP window size: 22.9 KByte (default) >>> ------------------------------------------------------------ >>> [ 3] local 192.168.1.117 port 36450 connected with 192.168.1.102 port >>> 5001 >>> [ ID] Interval Transfer Bandwidth >>> [ 3] 0.0-10.1 sec 7.50 MBytes 6.25 Mbits/sec >>> >>> >>> I will try it tomorrow at school, where I have the most of the problems. >>> >>> >>>> Those numbers could probably be improved, but without any details on how >>>> the >>>> chip works, what could one do. Messing with power settings on the >>>> amplifiers >>>> could lead to destruction of radios. I cannot take that chance. >>> >>> >>> Im ok with that. When I was talking about the power is because I have >>> read somwhere that there were problems with power management in the >>> driver. I am trying to get working another wireless card in a router. >>> I could be confused about the power problem. >>> >>>> >>>> As to stability, I am in the middle of a long-term test of rtl8723ae. >>>> After >>>> roughly 86,000 seconds of connect time, I have had only 9 disconnections, >>>> and all were due to a bug in the roaming code that I have so far been >>>> unable >>>> to find. The interface thinks it has lost the APs beacons, does a >>>> disconnect, and immediately reconnects. Otherwise, the connection was >>>> stable >>>> until I forced a reconnect to my G AP for this reply. >>> >>> >>> Sorry for beeing the cause of this disconnection. I really appreciate >>> the work that you and others do so everyone can use FLOSS drivers. >>> >>>> Unfortunately, I have no idea what to do for your complaints. If you want >>>> higher throughput, then an 802.11n AP seems warranted. >>> >>> >>> The hope that we can replace the wireless home router soon. >>> >>> But for the AP on the school I can't do anything. Thay have spent a >>> lof of money buying HP AP with central management and I can't do >>> anything to change them. >>> >>>> Larry >>>> >>> >>> I think that the problems in the school can be because channel saturation. >>> >>> There are some APs reachable with the same SSID (every AP have 3 SSID >>> I think). But the other students doesn't have any problems. I have >>> checked with "other OS and the RTL drivers" on the laptop and the >>> connection is ok. >>> >>> It coluld be related with the bug with roaming? >>> >>> Any tip for diagnosing this? I can help you with the bug providing >>> data or doing any test? >> >> >> Please do not drop the mailing list from the reply. Always use >> "Reply-to-All". I have added the Cc on my reply, but because it was not on >> your mail, I dare not trim the reply. >> >> You will see messages like the following if you have the bug: >> >> finger@larrylap:~/realtek> dmesg | grep watchdog >> [24098.632094] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88203.348090] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88221.856380] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88228.360104] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88238.520095] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88346.876102] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88353.032106] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88377.196053] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> [88417.776110] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to >> reconnect now >> >> As you can see this happens quite infrequently. Finding it will not be easy. >> >> Larry >> > > > I have been testing a little bit. > Right now I am on the school. I've used watch to watch for the signal level. > It's stable at ~-50 dBm sometimes it drops to ~25dBm for a bit (less > than 1 second) > > When traffic increases the number of "Invalid misc" increases a lot. > For example for a Speed test of 1 minute of duration it increases 800. > > The performance for the moment is acceptable. I will do more test when > the performance drops. > > I haven't had any message related with the roaming bug. > > Any tool for doing better diagnostics that I can use? > > Thank you a lot. > > David -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
