Difference between Atheros and MediaTek?

Hello, after reading some, I see some people prefer Qualcomm Atheros to MediaTek but I can´t find why, so why its better and its a substantial difference?

Because of open source drivers

2 Likes

So its a problem of drivers? But Media also have open source drivers and both require non free firmware. I'm not seeing what you want to say.

I think it's because ultimately, most routing devices are developed from reference boards that pair CPU and Wi-Fi chips obtained from the same company (e.g. Qualcomm ath10k & ipq808x; MediaTek mt76 & ramips). This results in the average Atheros device having access to a much more powerful CPU than their MediaTek counterparts, since Qualcomm manufactures some pretty beefy CPUs in their IPQxxxx lineup. Thus ultimately, QCA devices (on average) have much better routing throughput for NAT/VPN/SQM/Adblocking. Coupled with the fact that the majority of OpenWrt forum members are power users with higher end WAN speeds and play around with VLANs, this usually means CPU spec is more important than anything else.

When viewed with a scope of only looking at the level of open-source support for wireless drivers (WiFi AC), MediaTek's mt76 is actually better than QCA's ath10k because less of the functions are in the proprietary binary blob. However, in the past, QCA was king with their ath9k (WiFi N) driver.

3 Likes

Ok so in similar cpu MediaTek gets the win?
I have found this ath10k and this mt76 , the ath10k have a not small bugs list.

CPU drivers don't really exist on Linux (barring frequency scaling/PMIC). Unless you're talking about microcode updates or the like. As far I know however, only x86(-64) processors come with microcode requirements in the kernel, and even then microcode is usually a closed source binary for most, if not all cases. Ultimately, the stability of the CPU is decided by the stability of the specific Linux kernel version you're using and if it has the necessary workarounds if your CPU has errata.

The length of issues/bugs list shouldn't really be a factor. Most on the list that you have provided on the bottom of the page are edge/uncommon cases and configurations for the average user or, things that don't actually affect device operation (only affect device status reading). I also wouldn't look into the wiki, I'd probably look into a git/svn issue tracker for a more up to date snapshot on the current number of issues plaguing a specific driver.

For example, look at the repo for mt76. It has more issues than ath10k-ct (what the future OpenWrt 19.XX release will use). This could have arisen from the fact that mt76 devices are more affordable, thus more accessible for people and not because the mt76 driver is inherently more unstable. More users = many more variations in configuration = higher probability of discovering bugs.

Ultimately, both QCA and MT make decent chips for devices. If you were to limit yourself to these two chip manufacturers:

  • QCA devices will usually perform better in routing (router != access point) due to how they are usually paired with a better CPU than MT devices.

  • MT devices will have better support for wireless functions and features. Their stability with OpenWrt is also increased in part due to one of the driver devs being a keystone OpenWrt dev as well (Felix Fietkau). Bugs are addressed quickly in part due to how transparent the code is and how the devs operate.

  • Because QCA boards usually have stronger CPUs, they usually have higher throughput for VPN/NAT/SQM/etc i.e. (routing).

  • Because MT boards have a stabler WiFi driver interface, they are better wireless access points.

2 Likes

Mediatek mt76 wireless devices need a smaller firmware than their Qualcomm Atheros ath10k counterparts. Qualcomm Atheros even went so far as to replicate a lot of standard wireless functionality and lock it in their firmware blob.

1 Like

QCA devices are usually slower at routing. The R7800 uses an stmac Ethernet device which is slow. It can't do line speed, even with flow offload enabled. The MIPS ones can with flow offload.

1 Like

The number of antennas doesn´t count in terms of been better as wireless extender? For example the Archer C6 - ath10k with 5 shouldn't be better than Netgear r6220 -mt76 with 2 as extender because of the number of antennas?

Does any of that 2 routers have problems to make work relayd? Will be bad to me if it does.

If you're looking for a range extender, you should understand that if it is a single-band device that you'll have half (or less) of the bandwidth available to you; get a packet, send that packet in the next time slot.

True three-radio devices, such as the EA8300 (or a couple others already available on master), can have two, independent 5 GHz radios which don't have this halving "problem" as one can be repeating while the other is accepting the next packet.

You should also know that relayd is fragile, and doesn't handle IPv6 at all. A "Layer 2" approach, such as WDS, batman-adv, or GRE tunnels is, in my opinion, much more robust.

4 Likes

Available where exactly? master gives me non related search results.
Its dual band so if I receive in 5 GHz and extend in 2.4 GHz will not resolve the time slot problem?

I'm connected without IPv6 so no big deal I think.
Witch the one of Layer 2 approach you think can be done in a easy way without accessing the AP control panel?

Backhaul on 5 GHz and AP on 2.4 GHz will limit you to 2.4 GHz speeds, if that is acceptable to you.

You'd need to check these devices for their capabilities, including if the third radio is fully functional, but the ones that suggest (from the DTS source) that they have three radios that are already on master (EA8300 is at the PR stage) include

$ find target/linux -name '*.dts' -exec fgrep -H wifi2 {} \; | fgrep '@' | fgrep 4.14
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-a62.dts:		wifi2: wifi@1,0 {
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts:		wifi2: wifi@1,0 {
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-mr33.dts:		wifi2: wifi@1,0 {

I can't speak to the quality or performance of any of the above as I don't own any of them

I receive in both bands so I can experiment in witch band its better to extend.
EA8300 its out of budget and how I see what models are in that links?

Amazon US pricing of the moment:

Open-Mesh A62 Universal Tri-Band 802.11ac Wave 2 Cloud-Managed WiFi Access Point -- $309

ASUS Home Wi-Fi System, Pack of 3 (for large homes), Tri-Band Mesh Networking Wireless AC2200 Routers with AI Protection - MAP-AC2200 -- $309

Cisco Meraki MR33 Wave 2 Access Point (3 Radios, 2.4GHz and 5GHz, Dual-Band, 802.11ac, POE, Requires Cloud License) -- $345

Linksys Max-Stream AC2200 MU-MIMO Tri-Band WiFi Router for Home (Fast Wireless WiFi Router, Gigabit Wireless Router) -- $144 (These have been as low as $115)

Linksys Max-Stream AC2200 MU-MIMO Tri-Band Wireless Router, Works with Amazon Al -- $60 (refurbished)

1 Like

The cheapest 2, the Linksys EA8300 dont have OpenWrt support, nor I have found support for any tri-band from Linksys.

2 Likes

Ok, I was looking here Available hardware .

One thing, I don't understand, if I have a router not tri-band but dual band instead, and 2 antennas are in same frequency, lets say 2.4 GHz, can not 1 antenna only receive and the other antenna only emits so will be no slow packets working as extender?

In here Support ea8300 (Dallas), its the mac80211 working already?
And, its jeffsf ea8300 the updated snapshot with the last commits? If yes, it works with the EU model?
Finally, the device can be unbrick in case anything goes wrong?

No, you would need a dedicated radio for that (a third radio), on a different channel - after all the receiving channel is congested and your can only send once the air is clear again (WLAN is half-duplex).

No, the pull request hasn't been merged into OpenWrt master yet, but you can apply it to your local OpenWrt/master clone and build it yourself.

Like many other high(er) end Linksys devices, the EA8300 comes with a dual-boot setup (meaning you can switch to the previously working partition after invoking three failed reboots). Recovery via serial console and tftp is available, if there is something like a push-button tftp recovery method is something you'd have to ask someone with the device, e.g. jeff.

2 Likes

Yes, all three radios are working well for me. There's some more information on the device at https://openwrt.org/inbox/linksys/linksys_ea8300 (which I will need to update at some point soon). Note that the two, 5 GHz radios operate on different portions of the band (probably a good idea anyways).

slh is spot on for the build approach needed before the Pull Request is accepted and merged. No, I don't know when that might be.

The device should work with the EU variant, though I don't have one that I can try with myself. I can try to find the GPL drop for the EU version (or if you do, let me know where you downloaded it from) and confirm that the partitioning is the same.

The PR is presently set up for the FCC "cal" data which should provide reasonable performance with the EU model. I have already packaged the EU (and IC and AP) variant cal data in the PR. If you build your own firmware, at the bottom of target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-linksys_ea8300.dts you'll see three sections that look like

&wifi0 {
        status = "okay";
        qcom,ath10k-calibration-variant = "linksys-ea8300-fcc";
};

If you change that to linksys-ea8300-eu in each, it should pick up the EU cal data. I don't have the "magic decoder ring" for that Qualcomm/Atheros format, but it would surprise me if it dramatically alters the wireless performance. Note that this is the "generic" data for the radios and that each unit has its own specific data that is combined with this for "fine tuning" of the radio. At some point I was going to look into "device-tree overlays" to allow a single ROM to be used for any of the variants, but haven't gotten there yet to evaluate the possibilities further.

The factory images built will flash through the factory GUI. There are ways to avoid signing up for a Linksys Smart Router (?) account when you boot the router. As I recall, not plugging in the WAN cable makes it easier. Even if you do, you can still reset to OEM defaults and start fresh.

I have not found a solder-less way to enter the boot loader.

As slh points out, it is a dual-firmware unit that can be swapped to the other partition from OpenWrt, or will do so automatically after three failed boots.

1 Like