| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| toh:recommended_routers [2019/10/23 17:52] – [Are "Snapshot" Devices Supported?] jeff | toh:recommended_routers [2023/11/09 22:17] – move wsm20 to the correct place knarrff |
|---|
| Purchase of a device with less than 16 MB of flash or less than 128 MB or RAM is unwise at this time (2019). | Purchase of a device with less than 16 MB of flash or less than 128 MB or RAM is unwise at this time (2019). |
| |
| A device with two, "ath10k" radios should have at least 256 MB of RAM. This eliminates the Asus RT-AC58U and similar. | A device with two, "ath10k" radios should have at least 256 MB of RAM. This eliminates the Asus RT-AC58U, RT-ACRH13, and similar. |
| </WRAP> | </WRAP> |
| |
| Platforms that have less than 16 Mbyte of flash **will have** noticeable space constraints. Having less than 128 Mbyte of RAM also imposes limitations, basic network functionality may work however there are reports of **memory errors** while using opkg and luci among other services which may operate **unreliable or in worst case freeze the system**. Support for either 4 MB of flash or 32 MB of RAM has already been discontinued, due to the size of the Linux kernel and run-time footprint of the third-party software required for a basic, running OpenWrt system. One should expect that 64 MB RAM will be unsupportable in the near future, as well as support for 8 MB of flash. | Platforms that have less than 16 Mbyte of flash **will have** noticeable space constraints. Having less than 128 Mbyte of RAM also imposes limitations, basic network functionality may work however there are reports of **memory errors** while using opkg and luci among other services which may operate **unreliable or in worst case freeze the system**. Support for either 4 MB of flash or 32 MB of RAM has already been discontinued, due to the size of the Linux kernel and run-time footprint of the third-party software required for a basic, running OpenWrt system. One should expect that 64 MB RAM will be unsupportable in the near future, as well as support for 8 MB of flash. |
| |
| A device with two, "ath10k" radios should have at least 256 MB of RAM for stable operation. This eliminates the Asus RT-AC58U and similar. | A device with two, "ath10k" radios should have at least 256 MB of RAM for stable operation. This [[https://forum.openwrt.org/t/asus-rt-ac58u-crashes-under-heavy-load-after-a-while/33008?u=jeff|eliminates the Asus RT-AC58U, RT-ACRH13]], and similar. |
| |
| For many opinions, see the OpenWrt Forum. For example [[https://forum.openwrt.org/search?q=favorite%20device|https://forum.openwrt.org/search?q=favorite%20device]] | For many opinions, see the OpenWrt Forum. For example [[https://forum.openwrt.org/search?q=favorite%20device|https://forum.openwrt.org/search?q=favorite%20device]] |
| ==== Are "Snapshot" Devices Supported? ==== | ==== Are "Snapshot" Devices Supported? ==== |
| |
| Yes, devices are supported by OpenWrt "snapshots" until a formal release includes the device. In many cases, a newer device (or one that has recently had OpenWrt ported to it) will only be available as a snapshot build for months (or even over a year) before a formal release includes it. Snapshot (or ''master'') builds and code are not necessarily "less stable" than "release" builds. In many cases the snapshot build will outperform a release build, or resolve issues found in the release builds. The main challenge for many users with snapshot builds are that they don't come with LuCI (GUI) preinstalled, and many "special" packages a user wants to add generally need to be flashed when the ROM is downloaded and flashed. See further [[releases:snapshot|Development builds / snapshots]] | Yes, devices are supported by OpenWrt "snapshots" until a formal release includes the device. |
| | |
| | In many cases, a newer device (or one that has recently had OpenWrt ported to it) will only be available as a snapshot build for months (or even over a year) before a formal release includes it. Snapshot (or ''master'') builds and code are not necessarily "less stable" than "release" builds. In many cases the snapshot build will outperform a release build, or resolve issues found in the release builds. |
| | |
| | The main challenge for many users with snapshot builds are that they don't come with LuCI (GUI) preinstalled, and many "special" packages a user wants to add generally need to be flashed when the ROM is downloaded and flashed. Getting LuCI up and running is easily resolved with an Internet connection, SSH client, and [[docs:guide-user:luci:luci.essentials|a couple of simple commands]]. |
| | |
| | See further [[releases:snapshot|Development builds / snapshots]] |
| |
| |
| The Ethernet switch //usually// is limited only by the speed of its "phy", the portion that connects to an Ethernet cable. A device with a 100 Mbps phy will be limited to ~95 Mbps //throughput//. A 1000 Mbps phy is //not// a guarantee that the overall device can achieve gigabit rates. For most users working with a reputable manufacturer, it is sufficient to know that the switch and phys in the device were likely properly matched to the rest of device. | The Ethernet switch //usually// is limited only by the speed of its "phy", the portion that connects to an Ethernet cable. A device with a 100 Mbps phy will be limited to ~95 Mbps //throughput//. A 1000 Mbps phy is //not// a guarantee that the overall device can achieve gigabit rates. For most users working with a reputable manufacturer, it is sufficient to know that the switch and phys in the device were likely properly matched to the rest of device. |
| |
| The next bottleneck is the connection between the switch and the CPU. This is, unfortunately, not visible to most end users. One point to remember is that often (2019) this is a single "[R]GMII" connection that is limited to 1 Gbps, raw, so bonding ports on the switch doesn't overcome this limitation. Some devices have two gigabit-rate internal links, which are sometimes configured for WAN and LAN. | The next bottleneck is the connection between the switch and the CPU. This is, unfortunately, not visible to most end users. One point to remember is that often (2019) this is a single "[R]GMII" connection ([reduced] [[wp>Media-independent_interface#Gigabit_media-independent_interface|gigabit media-independent interface]]) that is limited to 1 Gbps, raw, so bonding ports on the switch doesn't overcome this limitation. Some devices have two gigabit-rate internal links, which are sometimes configured for WAN and LAN. |
| |
| The CPU, in most devices, needs to handle the packet flow, including firewall, connection tracking, and NAT. It also needs to handle every packet for SQM, as well as other tasks, such as DNS, DHCP, VPN, logging, time keeping, ..., as well as any "unnecessary" functions such as GUI or end-user firmware. For most all-in-one routers, this is a primary bottle neck. As Internet speeds have increased, the ability to do this "effortlessly" with a cheap, single-core CPU has been stressed. A multi-core CPU lets one work with the traffic, while another can handle the other moment-to-moment demands. With the computational loads of a VPN, a multi-core CPU becomes even more attractive. | The CPU, in most devices, needs to handle the packet flow, including firewall, connection tracking, and NAT. It also needs to handle every packet for SQM (smart queue management), as well as other tasks, such as DNS, DHCP, VPN, logging, time keeping, ..., as well as any "unnecessary" functions such as GUI or end-user firmware. For most all-in-one routers, this is a primary bottleneck. As Internet speeds have increased, the ability to do this "effortlessly" with a cheap, single-core CPU has been stressed. A multi-core CPU lets one work with the traffic, while another can handle the other moment-to-moment demands. With the computational loads of a VPN, a multi-core CPU becomes even more attractive. |
| |
| Because there are tasks other than just routing the traffic, the throughput doesn't scale directly with CPU speed. For example, going from 500 MHz to 750 MHz clock with the same CPU core is going to be //less// than 50% faster, often a lot less. | Because there are tasks other than just routing the traffic, the throughput doesn't scale directly with CPU speed. For example, going from 500 MHz to 750 MHz clock with the same CPU core is going to be //less// than 50% faster, often a lot less. |
| * ipq806x (QCA wireless) | * ipq806x (QCA wireless) |
| * ipq40xx (QCA wireless) | * ipq40xx (QCA wireless) |
| | * mediatek (MTK wireless) |
| |
| The mvebu units tend to be the highest performance. The ipq40xx units tend to be available at lower price points. | The mvebu units tend to be the highest performance. The ipq40xx units tend to be available at lower price points. |
| ==== x86_64/AMD64 ==== | ==== x86_64/AMD64 ==== |
| |
| For those desiring "true" gigabit throughput or high-speed VPN, a low-power, x86_64/AMD64 SBC or ITX with AES-NI and dual NICs is an option. With proper component selection, such devices can actually consume //less// power than a high-end, all-in-one router, even when paired with a suitable AP for wireless. | For those desiring "true" gigabit throughput or high-speed VPN, a low-power x86_64/AMD64 SBC (single-board computer) or an ITX board ([[wp>Mini-ITX|Information Technology eXtended]], a small motherboard form-factor) with AES-NI (Intel's [[wp>AES_instruction_set#x86_architecture_processors|Advanced Encryption Standard New Instructions]]) and dual NICs is an option. With proper component selection, such devices can actually consume //less// power than a high-end, all-in-one router, even when paired with a suitable AP for wireless. |
| |
| ==== Wireless ==== | ==== Wireless ==== |
| |
| //Virtually no 802.11 link between a consumer AP and phone, laptop, or desktop in the real world can reliably support gigabit throughput.// | **//Virtually no 802.11 link between a consumer AP and phone, laptop, or desktop in the real world can reliably support gigabit throughput.//** |
| |
| Wireless tends to be supplied by the SoC's designer. Almost always the wireless components are part of the SoC and, if they use a second chip set, are from the same vendor. | Wireless tends to be supplied by the SoC's designer. Almost always the wireless components are part of the SoC and, if they use a second chip set, are from the same vendor. |
| You can't judge the performance of an antenna by its looks. Big, fat antennas generally aren't any better than skinny ones. Well-executed patch antennas or internal antennas can be every bit as good as impressive-looking external antennas. For a variety of reasons, using external antennas on feed lines is often a net loss (exceptions being for professional-quality antennas and feed lines for point-to-point links, which often cost more than a high-end router for just one). | You can't judge the performance of an antenna by its looks. Big, fat antennas generally aren't any better than skinny ones. Well-executed patch antennas or internal antennas can be every bit as good as impressive-looking external antennas. For a variety of reasons, using external antennas on feed lines is often a net loss (exceptions being for professional-quality antennas and feed lines for point-to-point links, which often cost more than a high-end router for just one). |
| |
| | === QCA Wireless === |
| | |
| | The Atheros or Qualcomm Atheros ([[wp>Qualcomm_Atheros|QCA Wireless]]) SoCs and chip sets are common, have long-established open-source support with both the upstream (Linux) ath-series drivers and firmware, as well as the ath10k-CT ([[https://www.candelatech.com/ath10k.php|Candella Technologies]]) drivers, currently "default" with OpenWrt (v19). Support for advanced features such as IBSS and 802.11s tends to be good with the recent chip sets under both the upstream drivers, as well as the ath10k-CT drivers. |
| | |
| | older "Wave 1" devices, such as the Archer C7v2, may need to use the non-CT drivers for 802.11s support. |
| | |
| | "ath9k" devices are not "better" or "worse" than "ath10k" devices. |
| | |
| | === MTK Wireless === |
| |
| The Atheros or Qualcomm Atheros (QCA) SoCs and chip sets are common, have long-established open-source support with both the upstream (Linux) ath-series drivers and firmware, as well as the ath10k-CT ([[https://www.candelatech.com/ath10k.php|Candella Technologies]]) drivers, currently "default" with OpenWrt (v19). Support for advanced features such as IBSS and 802.11s tends to be good with the recent chip sets under both the upstream drivers, as well as the ath10k-CT drivers (older "Wave 1" devices, such as the Archer C7v2, may need to use the non-CT drivers for 802.11s support). "ath9k" devices are not "better" or "worse" than "ath10k" devices. | |
| |
| FIXME: Help describing MTK drivers | FIXME: Help describing MTK drivers |
| | |
| | === Marvell Wireless === |
| | |
| |
| FIXME: Help describing Marvell drivers - please note issues with IBSS and 802.11s | FIXME: Help describing Marvell drivers - please note issues with IBSS and 802.11s |
| | |
| | === Broadcom Wireless === |
| | |
| |
| FIXME: Which Broadcom wireless chips have meaningful support? | FIXME: Which Broadcom wireless chips have meaningful support? |
| |
| |
| **//Remember that if you want to use SQM or similar, offload generally can't be used.//** | **//Remember that if you want to use SQM (Smart Queue Management) or similar, hardware flow offloading can't be used.//** |
| |
| As discussed above, quite a bit of CPU resources are consumed doing routing and NAT functions. Since router-SoC manufacturers know that device reviewers will measure the throughput of the device under well-known conditions, they often include specialized hardware into the SoC to be able to "offload" basic routing and NAT from the CPU itself. This is a cost-effective way to get "better" numbers and "marketing bullets" for those that use their SoCs ("Full, gigabit routing" or the like). | As discussed above, quite a bit of CPU resources are consumed doing routing and NAT functions. Since router-SoC manufacturers know that device reviewers will measure the throughput of the device under well-known conditions, they often include specialized hardware into the SoC to be able to "offload" basic routing and NAT from the CPU itself. This is a cost-effective way to get "better" numbers and "marketing bullets" for those that use their SoCs ("Full, gigabit routing" or the like). |
| This specialized hardware often requires closed-source drivers and/or proprietary information from the SoC manufacturer to utilize robustly. As a result, //hardware// offload to the switch, or to things like NSS cores in the IPQ806x devices, is generally not supported with open-source firmware. This is often the reason why //any// third-party firmware doesn't match the LAN <=> WAN, NAT-only throughput of OEM firmware. | This specialized hardware often requires closed-source drivers and/or proprietary information from the SoC manufacturer to utilize robustly. As a result, //hardware// offload to the switch, or to things like NSS cores in the IPQ806x devices, is generally not supported with open-source firmware. This is often the reason why //any// third-party firmware doesn't match the LAN <=> WAN, NAT-only throughput of OEM firmware. |
| |
| However, if you use SQM (bandwidth shaping, "bufferbloat" mitigation) or similar functionality, you generally can't use flow offloading (software or hardware). Functions like SQM require each packet to be handled by the the CPU, so the various software or hardware "shortcuts" can't be used. Even with high-bandwidth connections, SQM can greatly reduce "lag", improve responsiveness of Internet browsing, and make VOIP and FaceTime calls smoother. OEM firmware generally doesn't support SQM, so no direct comparison is possible. | However, if you use SQM (bandwidth shaping, "bufferbloat" mitigation) or similar functionality, you generally can't use hardware flow offloading, but software flow offloading [[https://forum.openwrt.org/t/software-flow-offloading-implications/90957|seems to work]]. Functions like SQM require each packet to be handled by the the CPU, so the various hardware "shortcuts" can't be used. Even with high-bandwidth connections, SQM can greatly reduce "lag", improve responsiveness of Internet browsing, and make VOIP and video calls smoother. OEM firmware generally doesn't support SQM, so no direct comparison is possible. |
| |
| Flow offload generally does not improve VPN performance significantly as the limitations there come primarily from the CPU and its ability to encrypt/decrypt the packets and move them between interfaces. | Flow offload generally does not improve VPN performance significantly as the limitations there come primarily from the CPU and its ability to encrypt/decrypt the packets and move them between interfaces. |
| OpenWrt officially supports software flow offload on several SoCs, which can greatly speed "NAT-only" configurations. At this time (2019), the MT7621A is the only device on which OpenWrt supports //hardware// offload. | OpenWrt officially supports software flow offload on several SoCs, which can greatly speed "NAT-only" configurations. At this time (2019), the MT7621A is the only device on which OpenWrt supports //hardware// offload. |
| |
| ===== Older content (2016?) follows below ===== | |
| |
| | ---- |
| |
| |
| | ===== Older content (2016?) follows below ===== |
| | |
| | <WRAP center round important 60%> |
| | **Many devices listed below are outdated and no longer recommended (2019)** |
| | </WRAP> |
| |
| |
| filter : Model=TL-WDR4300 | filter : Model=TL-WDR4300 |
| ---- | ---- |
| **US lockdown notes goes here** | **US lockdown notes go here** |
| |
| * **QCA95XX** are the latest family of MIPS based SoCs by QCA and provide a slight boost in performance (~10-15%) compared to the AR934*-series because of the higher clock frequency. These systems are usually shipped with ath10k radios which supports 11ac however these drivers need to rely more on the firmware blob which makes improving the driver hard. Wifi performance peaks at about 400mbit depending on conditions. | * **QCA95XX** are the latest family of MIPS based SoCs by QCA and provide a slight boost in performance (~10-15%) compared to the AR934*-series because of the higher clock frequency. These systems are usually shipped with ath10k radios which supports 11ac however these drivers need to rely more on the firmware blob which makes improving the driver hard. Wifi performance peaks at about 400mbit depending on conditions. |
| filter : Versions=v2 | filter : Versions=v2 |
| ---- | ---- |
| **US lockdown notes goes here** | **US lockdown notes go here** |
| |
| ---- datatable ---- | ---- datatable ---- |
| |
| A quite well supported platform, it has 2 cores and 2 threads (somewhat similar to Hyperthreading on x86) along with a more powerful core (MIPS 1004Kc) which makes this SoC about about twice as fast as the AR934X-series (depending on application). These are typically shipped with 11ac hardware and the driver (mt76) works fairly well, it's still under development but is more open than the ath10k driver making it a more interesting choice for the Open Source community. Generic throughput numbers are about 400-500mbit/s (LAN-WAN without PPPoE) and ~45mbyte/s using the USB3 interface. It's also worth noting that products using this SoC are usually cheaper or priced about the same as the Atheros 11n and 11ac counterparts but might be hard to come by. \\ | A quite well supported platform, it has 2 cores and 2 threads (somewhat similar to Hyperthreading on x86) along with a more powerful core (MIPS 1004Kc) which makes this SoC about about twice as fast as the AR934X-series (depending on application). These are typically shipped with 11ac hardware and the driver (mt76) works fairly well, it's still under development but is more open than the ath10k driver making it a more interesting choice for the Open Source community. Generic throughput numbers are about 400-500mbit/s (LAN-WAN without PPPoE) and ~45mbyte/s using the USB3 interface. It's also worth noting that products using this SoC are usually cheaper or priced about the same as the Atheros 11n and 11ac counterparts but might be hard to come by. \\ |
| |
| :!: As of writing there's **no working** VLAN support in the switch for this SoC. \\ | |
| :!: Currently, it may have stability issues if you are using more than one wireless network (wifi-iface) for each radio (wifi-device) | |
| |
| ---- datatable ---- | ---- datatable ---- |
| cols : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page | cols : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page |
| header : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page | header : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page |
| align : c,c,c,c,c,c,c,c,c,c,c,c,c | align : c,c,c,c,c,c,c,c,c,c,c,c,c |
| filter : Model=DIR-860L | filter : Model=DIR-860L |
| ---- | ---- |
| ---- datatable ---- | ---- datatable ---- |
| cols : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page | cols : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page |
| header : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page | header : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page |
| align : c,c,c,c,c,c,c,c,c,c,c,c,c | align : c,c,c,c,c,c,c,c,c,c,c,c,c |
| filter : Model=WF-2881 | filter : Model=WF2881 |
| | ---- |
| | ---- datatable ---- |
| | cols : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet 1Gbit ports_, Modem, USB ports_, Device Page_page |
| | headers : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB |
| | align : c,c,c,c,c,c,c |
| | filter : Brand=ZyXEL |
| | filter : Model=WSM20 |
| ---- | ---- |
| |
| === Marvell Armada 385 aka 88F6820 === | === Marvell Armada 385 aka 88F6820 === |
| |
| This is a relatively new platform based on ARM compared to the other ones here that are MIPS based. It offers the best performance but is also in general the most expensive one. It offers 2 cores running at 1.6Ghz and does linespeed NAT. It's usually coupled with wifi using the mwlwifi driver which is considered unstable for now and may crash the system occationally. Wired performance and stability is good(?), USB (status?), SATA (status?) however. As of writing there are no known user friendly products available that OpenWrt supports, serial access is needed for recovery and stability isn't (yet) up the standard of the other platforms. | This is a relatively new platform based on ARM compared to the other ones here that are MIPS based. It offers the best performance but is also in general the most expensive one. It offers 2 cores running at 1.6Ghz and does linespeed NAT. It's usually coupled with wifi using the mwlwifi driver which is considered unstable for now and may crash the system occasionally. Wired performance and stability is good(?), USB (status?), SATA (status?) however. As of writing there are no known user friendly products available that OpenWrt supports, serial access is needed for recovery and stability isn't (yet) up the standard of the other platforms. |
| |
| === MediaTek MT7620A === | === MediaTek MT7620A === |
| Below are some models reported stable. | Below are some models reported stable. |
| ---- datatable ---- | ---- datatable ---- |
| cols : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page | cols : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet 1Gbit ports_, Modem, USB ports_, Device Page_page |
| header : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page | header : Brand, Model, Version,Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB |
| align : c,c,c,c,c,c,c,c,c,c,c,c,c | align : c,c,c,c,c,c,c,c,c,c,c,c,c |
| filter : Brand=Lenovo | filter : Brand=Lenovo |
| filter : Model*~Y1 | filter : Model*~Y1 |
| ---- | ---- |
| | |
| **Needs confirmation:** Buffalo WHR-1166D seems to be suitable? | **Needs confirmation:** Buffalo WHR-1166D seems to be suitable? |
| |