OpenWrt router for 1Gbps?

It would be a lot better if you could link to the posts that contain that information instead of just listing the affected users.

https://forum.openwrt.org/t/add-support-for-linksys-ea6350-v3/18907/327?u=moeller0

"My 300 Down /12 Up line with SQM enable (cake and piece of cake) get 180 Down /8 Up."

@jeff is testing with NAT and firewall (but without PPPoE and SQM), I see no issue reconciling these data points. About @DreamAddict I am unsure since his issue is not described verbosely enough, but he gets ~349 Mbps LAN to USB-dongle on laptop (many USB dongles are crap and USB2 top out at a gross rate of 480 Mbps anyway), 63.2 Mbps on 2.4GHz radio and 2,5 Mbps on 5GHz radio, since we do not know about his RF environment and number of overlapping users of the different frequency bands (let alone the capability of his laptop) this sounds about what you can expect in real life.

I am sorry, I feel your pain and lack of satisfaction with OpenWrt on your router, but insulting other users here that are actively trying to help seems counter-productive to improve your situation, no?

:confused:

User DreamAddict This is with Ethernet or Wifi.

Where is this imaginary insult that you're trying to stir and troll with?

edit

If you're referring to the fake results comment of Iperf then that was at the tool itself and not Jeff?

The internet has been full of people questioning the results of iperf for years as being false or fake in comparison to real life.

https://iwl.com/idocs/does-iperf-tell-white-lies

Please read what I wrote, "but he gets ~349 Mbps LAN to USB-dongle on laptop" that is what you call ethernet, but due to the USB-dongle involved I consider this not to be proof that the router is to blame (it also does not clear the router, but it makes this data point hard to interpret without more verbose description and tests)

Calling @jeff's iperf data fake is insulting in my book, I guess it was not intended that way.

2 Likes

Like any benchmarking tool, you have to know what iperf measures and how it measures it. Not iperf is questionable, but the interpretation of the results. The article you link even concedes that they misinterpreted the numbers before reading the iperf manual, but of course that doesn't make for a good clickbaity headline.

1 Like

Sorry, everybody has the "right" to make him/herself a fool on the internet, this is why one needs to take the internet's information (and opinions) with a grain of salt. But sure benchmarking is hard :wink:

Had you taken the time to read that article, you would have seen

In particular, we observed that Iperf was significantly under reporting the actual bandwidth of the link.

The numbers reported by Iperf are not incorrect. Rather they are potentially misleading to those who do not realize that Iperf is measuring only transport level data and who expect that the result will be that raw bandwidth of the link, such as that advertised by ISPs or many consumer link speed test websites.

So your reference supports that the bandwidth measured by iperf is actually less that the underlying media. Note that my post of the iperf results indicated that the theoretical limit for throughput was ~940 Mbps, taking this into account already.

I'm also well aware that PPS (packets per second) is a more telling metric of router performance. However, for an audience that does not understand basic networking concepts, translating PPS performance into "Is it fast enough for my XXX Mbps line?" is challenging.

Further, comparison of the count of "problematic" responses on a support line or website against those of users reporting not having problems is not indicative of the issues with the unit. People who don't have problems don't generally take the time to write a post or make a call saying "Hey, your product works just like you said it would."

Finally, you somehow seemed to miss a post not far down from the ones you hand selected, from a user that I believe you respect, as I recall you asking them specific questions:

Well as long as you're all happy , you could have said to start with that your Linksys Router is the one to buy (for close to) 1Gbps internet throughput considering you get 900Mbps with openwrt.

No, I couldn't say that, nor can I make any blanket statements about any consumer-grade device as it depends on what you wan't to do with your 1 Gbps. As examples:

  • Is it symmetric? If so, is it full loaded in both directions?
  • Are you primarily sending ~1500 byte packets, or small packets (such as VOIP)?
  • Do you intend to run SQM, if so, which algorithm?
  • What is your tolerance to latency?
  • Are you expecting VPN throughput consistent with that transport rate? If so, which technology does your VPN use?
  • Are you expecting to load up your router with all kinds of non-essential services?

Well that's solved then.

OpenWrt: 920 Mbps
Wire: 927 Mbps

Can you clarify if your router's NAT was involved for these results?

jeff@test:~$ cat /etc/config/firewall 
config defaults
	option syn_flood	1
	option input		ACCEPT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

config zone
	option name		lan
	list   network		'lan'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT

config zone
	option name		wan
	list   network		'wan'
	list   network		'wan6'
	list   network		'wg0'
	list   network		'tun0'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT
	option masq		1
	option mtu_fix		1

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option src_ip		fc00::/6
	option dest_ip		fc00::/6
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

# include a file with users custom iptables rules
config include
	option path /etc/firewall.user


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option dest		wan
#	option proto	tcp
#	option target	REJECT

# block a specific mac on wan
#config rule
#	option dest		wan
#	option src_mac	00:11:22:33:44:66
#	option target	REJECT

# block incoming ICMP traffic on a zone
#config rule
#	option src		lan
#	option proto	ICMP
#	option target	DROP

# port redirect port coming in on wan to lan
#config redirect
#	option src			wan
#	option src_dport	80
#	option dest			lan
#	option dest_ip		192.168.16.235
#	option dest_port	80
#	option proto		tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#	option src		wan
#	option src_dport	22001
#	option dest		lan
#	option dest_port	22
#	option proto		tcp

### FULL CONFIG SECTIONS
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port	80
#	option dest		wan
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp
#	option target	REJECT

#config redirect
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port		1024
#	option src_dport	80
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp

Edit: The ACCEPT on WAN is intentional, and not recommended for general use. This is a closed system with no access to unprotected networks.

So how is that a real life test downloading from a 1gbps internet provider?

Real life test on Virginmedia 350Mbps:

Archer c7 V2 stock firmware - full 350Mbps
EA6320 V3 stock firmware - full 350Mbps
EA6320 V3 OpenWrt standard settings - 200mbps

Real life test on Virginmedia 500Mbps at a friends house on his gear:
Asus RT-AC57U stock firmware - 480Mbps
EA6320 V3 stock firmware - (from memory around the same as it was over a week ago)
EA6320 V3 OpenWrt standard settings - 220Mbps
EA6320 V3 OpenWrt flow control enabled - dropped to 180mbps

2 different brand new EA6350 routers tested at completely different locations on different UBR segments to VirginMedia Cable ISP.

I can't tell form this config.
Is router's NAT active and in between iperf client and server, is your setup like this?
iperf client -> [ router lan -> router NAT -> router wan ] -> iperf server

sorry i found the answer- your setup exactly as i said:

But since you insist, here's performance of an IPQ4019 (EA8300) connected to the upstream server over a gigabit link to the WAN port, being fetched by a client of the LAN side of the OpenWrt router. NAT and standard OpenWrt firewalling is in effect. No "flow-offload" or other similar features have been enabled.

1 Like

This is a much better data point and certainly worth exploring. Does the EA6320v3 always run with its nominal frequency or does it do frequency/power scaling like the R7800? In that case it would be interesting to see how this performs with the performance governor.
Have a look at https://forum.openwrt.org/t/speedtest-new-package-to-measure-network-performance/24647 for a speedtest to run on your router that will also look at the frequency to some degree.

1 Like

suffice to say that even on a laptop there is a noticeable difference in performance when using performance vs ondemand governor

Good to know. The question driving my post was does the router model support different governor's/frequency scaling and do both OEM and OpenWrt firmware default to the same settings?

suffice to say that even on a laptop there is a noticeable difference
in performance when using performance vs ondemand governor

Good to know. My question primarily is does this router allow frequency scaling/power saving, if yes what are the defaults for stock OEM firmware versus OpenWrt?

Sadly it's not something i can test any longer as both routers have now been sold on.

I tried 3 different snapshots and it was the same every time , My friend was not going to put up with losing over 50% in speed and had enough and i was equally fed up with amount of time i was wasting testing so many routers to always end up with slower speeds than original stock.

An odd characteristic of the EA6350 with openwrt ( and the reason why i said download a big ISO in real life ) is that it would start at a higher speed for the first few percent of a download and then drop to 200mbps and just stay there , it was exactly the same with every snapshot i tried.

None of the routers on stock firmware showed this characteristic and stayed close to full speed for the entire download?

Any reason why no one is recommending Jeff's 900Mbps EA8300 too ajoeiam?