Posted: Wed Jun 03, 2020 13:59 Post subject: iPhone XS wireless streams, link rate and throughput
i've been having this issue ever since i got the iPhone XS, two iPhone XS and two iPhone XS Max. iPhone X and earlier worked well.
wireless link rate when connected to R7000P and in the same room is usually never more than 400mbps and when connected to R6700v3 is even worse , 150-175 mbps, sometimes gets better but thats the usual. both 5GHz interfaces, VHT80. same location, iPad Air 2 does 866mbps, intel AC3165 adapter does 433mbps, LG G7 does around 800mbps. Amazon Fire TV is in the next room and it does 650mbps.
the situation is much worse on 2.4GHz interface on both routers and other Broadcom MIPS as well (EA2700, E3000, WRT160nv3).
tried FreshTomato on R6700v3 and the result is the same.
now this is mostly due to something with the iPhone XS chipset or driver and Broadcom chipset routers and i reported to Apple, however, does anyone know how to solve it while on DDWRT?
Joined: 21 Jan 2017 Posts: 1248 Location: Illinois Moderator
Posted: Thu Jun 04, 2020 18:20 Post subject:
Taken from the wifi wiki's:
Because on 2.4ghz nearly all cell phones and tablets will limit their channel width to only 20MHz if they detect neighboring routers/wifi AP's and so 40MHZ wide communication will not be allowed; even if you enable HT40 on the router. Your mileage may vary by enabling HT40 on the router for phones and tablets. As far as Laptops/Desktops, they usually have a way to allow 40MHz wide channels in the advanced driver settings. Disable "Fat Channel Intolerant" to take advantage of 40MHz on Windows OS's. Using HT40 enables channel bonding by using 2x20 MHz wide channels together to equal 40Mhz; but, it's considered "not neighbor friendly" and discouraged by industry standards- as noted above for android & iPhone HT20 limit. Using HT40 may, but usually doesn't, create more interference for neighbors; it's usually not an issue unless you're in VERY packed/dense/congested wireless area like apartments-
HT40 allows your 802.11n devices to connect at their max rate: 300 Mbps (2x2:2 stream clients) and 400Mbps (2x2:2) for QAM256 enabled routers & clients. 400Mbps is very rare and was reported on an android device with custom ROM; most everything else will end up using 802.11n MCS rates of 300Mbps for a 2x2:2 stream. HT40 yields a large throughput increase and enables Atheros Super-G* on legacy clients. However, if Full (20 MHz) is used for 802.11n clients, their max connection speed will only be 144 Mbps (2x2:2 stream clients) and 173Mbps/193Mbps* (2x2:2 stream clients) with QAM256 enabled routers & capable clients. Legacy 802.11g clients supporting Super-G max connection speed will only be 54 Mbps.
*Note: 193mbps is not an officially recognized MCS index rate, but some devices have reported 193mbps vs 173; 173 is the maximum for 2x2:2 stream clients per 802.11ac industry standards.
Also, it sounds like the MU-MIMO bug that kills all BCM devices to only 1x1:1 stream. So turn that feature off. Only use implicit beamforming (That is SU-MIMO) Explicit beamforming is the newer 802.11AC (MU-MIMO) beamforming.
Explicit vs. Implicit Beamforming
There are two main types of beamforming. Explicit, which includes 802.11ac's standard method requires transmitter and receiver to exchange information about the radio channel.
Implicit beamforming, which is used in some 802.11n products, doesn't require support on both ends of the wireless link. Instead it infers channel characteristics based on lost frames.
forget wifi wiki, forget link rates, i put the iPhone XS and the iPhone 8 next to an AP, both connected to 2.4GHz, iPhone 8 speedtest downloads at 50mbps, iPhone XS at 8-15mbps, almost everytime. (not simultaneous)
same when connected to 5GHz AC, but to test throughput, i download from local NAS, iPhone 8 downloads at 400-450mbps and iPhone XS downloads at 200-250mbps.
regarding MU MIMO, it does nothing in my case, i tried it after i saw your post and found no difference at all, actually, the R6700v3 doesn't have MU-MIMO and iPhone XS performs even worse than when connected to R7000P.