LOL , Try downloading a dual layer 9GB ISO from the internet as a real life test on a high speed internet account and swap between stock and and openwrt instead of keep posting fake bench results of iperf?
Archer C7 v2 single core on stock firmware runs circles around a EA6350 quad core running openwrt for throughput.
brave heart
None of my results are "fake".
I would start looking at why your configuration and/or your ISP and/or your upstream content servers are causing your problems. I seriously doubt that it is OpenWrt on the ipq40xx platform that is limiting you.
9 GB, dual-layer ISOs delivered by HTTP seem to be rather difficult to find. Major OS distros seem to limit their sizes to 3-4 GB and DVD-sized images seem to often only be distributed by BitTorrent.
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.
As you can see, wget shows the throughput to be ~880 Mbps.
IPQ40xx on
stockOpenWrt firmware can easily do 800/900Mbps all day long on large 4.7GB iso files
$ wget -O /dev/null http://10.0.0.2/pgdvd042010.iso
--2019-08-22 11:01:54-- http://10.0.0.2/pgdvd042010.iso
Connecting to 10.0.0.2:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8358395904 (7.8G) [application/octet-stream]
Saving to: ‘/dev/null’
/dev/null 100%[======================================================================================>] 7.78G 110MB/s in 73s
2019-08-22 11:03:07 (110 MB/s) - ‘/dev/null’ saved [8358395904/8358395904]
For reference, a direct connection yielded the same result
2019-08-22 11:17:41 (110 MB/s) - ‘/dev/null’ saved [8358395904/8358395904]
There was no measurable degradation (>1%) in throughput due to the insertion of the OpenWrt router in the path.
Edit: Re-ran based on suggestion to specify --report-speed=bits
OpenWrt: 920 Mbps
Wire: 927 Mbps
Still less than 1% difference
[TANGENT]
For these kind of measurements wget's --report-speed=bits option is quite nice in that it reports the transfer speed in bits instead of Bytes.
[/TANGENT]
User 4C696E6B737973575254 180 Down /8 Up.
User DreamAddict This is with Ethernet or Wifi. The speeds for both are also very poor. It doesn't seem steady or to be able to exceed 150mpbs.
Just a couple , but as long as your getting close to full speed we all must be wrong.
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?
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.
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.
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.
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 
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:
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.
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.