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
