Tp link 802.11ac driver install#
Tp link 802.11ac driver driver#
Tp link 802.11ac driver pro#
Tp link 802.11ac driver code#

(i) the whole 2.4 GHz spectrum is very crowded here where I live and the results would be skewed due to too much collision avoidance Testing on 2.4 GHz would be rather pointless for two reasons: I'm willing to provide more info but it would also help if you read my original report (I don't mean to be an ass by it, but I did provide detail there which answer both your posts so far). Apologies if you already stated this.ДЄre you an OpenWRT developer? I did state that on wired neither firmware has a problem and they hit 940+ Mbps. Did you test with both clients wired? Did you test on both bands of wireless? This would help narrow the problem. Isn't what's going on above LAN-LAN though? I thought the problem was only WAN-LAN.

Tp link 802.11ac driver code#

the code released by atheros is not compatible with several openwrt/dd-wrt features. No hardware NAT acceleration in openwrt or dd-wrt. On wired-to-wired I hit 940+ Mbits/s without much effort on both firmwares, which is expected since only the hardware ethernet switch is used in this case. any clues?ДЄre there any known kernel modules that take such a toll in OpenWRT? What modules are safe to disable for this simple test? (assuming nothing else is needed) Nothing I tried helped getting more throughput under TCP in OpenWRT. Checked the received power strength under both firmwares (under MacOSX > Wireless Diagnostics > Performance) and it was pretty much the same in both cases, around -40 dBm. Also tried using channel 149 so I could use 30 dBm Tx power (channel 36 was limited to 17dBm). I tried using both open (no auth) and WPA/WPA2. Fresh OpenWRT was flashed then the following issued: uci set =VHT80 uci set =0 uci commit wifi. If not, any pointers or ideas on what to try to improve it? See below things I've already tried.

Tp link 802.11ac driver driver#

I know TCP is more demanding on the CPU than UDP, so is the lower TCP throughput in OpenWRT due to the driver used? Obviously the router itself is capable of hitting 800+ Mbits/s. 8.0- 9.0 sec 195 datagrams received out-of-order 7.0- 8.0 sec 198 datagrams received out-of-order 6.0- 7.0 sec 327 datagrams received out-of-order 5.0- 6.0 sec 153 datagrams received out-of-order 4.0- 5.0 sec 160 datagrams received out-of-order 3.0- 4.0 sec 182 datagrams received out-of-order 2.0- 3.0 sec 152 datagrams received out-of-order (server, Mac): iperf -s -u -i 1 -w 1M -l 4K With a UDP buffer size of 1MB, iperf settings were: Using UDP instead of TCP, then both OpenWRT and TP-Link firmware yield around 800 Mbits/s. It is never as consistent or as high as the speed under the TP-Link firmware on when using TCP. Most of the time, the speed under OpenWRT drops to 200 Mbits/s or fluctuates between 200 and 500 Mbits/s. NOTE: That was the best score I managed to record. TP-Link firmware TCP results (latest TP-Link firmware from 11 Sept 2014) Otherwise you won't be able to hit 800+ Mbps. The other machine must be wired on a gigabit port. support tru 1300 Mbps PHY rate with aggregate AMPDU support (latter should be available by default) - using phones/tablets or devices that are not 3-stream AC1300 will not reveal differences. If you wish to test yourself, make sure the wireless machine is a true 3-stream (3x3 mimo) AC1300 801.11ac, i.e. The '-i 1' causes iperf to report speed every second. I used channel 36 and 149 with VHT80 (all other settings left on their defaults both channels give same results, 149 allows for higher Tx power). Channel fading is thus low and consistent. In all tests, the router sits at about half a meter in front of the laptop and the position is not changed, nor anything is moving in the room, while the tests are running.

Tp link 802.11ac driver install#

On Windows, I used the JPerf 2.0.2 package (GUI over iperf), while on MacOSX 10.10 I used iperf from Macports (just do 'port install iperf').

Tp link 802.11ac driver pro#

The wired one runs Windows 8.1 Pro and the wireless one runs MacOSX 10.10 (Macbook Pro late 2013), using the settings below. Is OpenWRT expected to be slower than native firmware under TCP? How about in general on various routers?Дoing an iperf test between two machines behind the router - one LAN (wired), one WLAN (wireless).