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?
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.
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?
Well, you ruled out x86 in your initial posting, unlike @ajoeiam, And he initially asked for a router that can directly connect to the fiber.
Also at Gbps rates, if one wants to actually do more than just NAT and fire-walling, x86 (and potentially mvebu) seem to be the only game in town (especially in the light of traffic shaping)*.
So in short, x86 seems future-proofer than EA8300, as @jeff wrote (https://forum.openwrt.org/t/openwrt-router-for-1gbps/42519/41?u=moeller0)) it really depends on
Finally nobody, including @jeff recommended the EA8300 unconditionally for Gbps-links, it was more about the claim whether under specific conditions it could sustain ~Gbps routing performance.
Best Regards
*) There are different opinions on whether at Gbps traffic-shaping is actually helping that much, but if one wants to maintain the capability to traffic shape at Gbps rates a suffieciently powerful CPU is required. Personally, I see traffic-shaping as still useful even at Gbps rates, but I admit to bias in this matter.
There seems to be a running theme on this forum of people having imaginary conversations?
"Rather avoid if i can" isn't ruling anything out if it can't be avoided , it's just a reference pertaining to what is “ least preferable ” due the extra clutter in the living room...
Yet another imaginary conversation when i specified real life.
People buy a consumer router and plug it into the wall and the internet and use it and can see in real life what speeds they get as throughput.
People convert a consumer router to openwrt then plug it into the wall and the internet and use it and can see in real life what speeds they get as throughput.
So can we all cut out the hypothetical imaginary BS under certain conditions crap and get to real life by using a router at stock settings as the starting point and ball park figure of throughput?
There are two types of people that race a quarter mile Dragstrip , those that actually get in their car and put real times down and then their are the BS lying type that put their car on a rolling road with a laptop plugged into the engine management and try to pass off fake numbers as racing the strip in real life.
The fantasizing of hypothetical is moronic and idiotic to the point of being cringeworthy and embarrassing , sorry if people can't handle a straight shooter but someone needs to call out the BS.
MT7621 will do at least Gbit one way if you use hardware acceleration however you can't use QoS/SQM and there are reports of instability while it seems to work "fine" for others. If you don't use hardware acceleration it'll do ~ 500mbit, you should also keep in mind that it's MIPS while most "high-performance" platforms are ARM or x86-64.
IPQ4*** "should" do Gbit (one way) under "normal circumstances" however performance will drop considerably if you add WLAN and/or VPN to the mix not to mention QoS/SQM.
IPQ8*** wont do Gbit due to driver issues however the hardware itself should be able to handle it fine but there are no news about the driver being improved/worked on within a reasonable timeframe to my knowledge.
mvebu will do Gbit (at least upper end) more or less both ways however not when using QoS/SQM and/or VPN or WIFI at the same time.You "should" be able to pull it off if you get Solidrun ClearFog GT 8K but it's not supported by OpenWrt (yet). https://github.com/openwrt/openwrt/pull/1646
That said, in terms of pricing and performance you might as well look at x86-64 if you're looking at the ClearFog GT 8K and since the hardware will be more powerful you might want to consider a distro that isn't as focused on binary size depending on your requirements.
Thanks Diizzy for taking the time to post all the information , i now understand and feel better informed of the current status of the OpenWrt project.
I'll keep a look out in the future for your forum posts as i respect people like yourself and @bill888 that get straight to the point.
Well, you asked "why no one is recommending Jeff's 900Mbps EA8300" and I gave you two reasons, both completely orthogonal to your unfortunate experience with OpenWrt in default settings on a different (but similar) SoC/router. I am not sure what you imagined our conversation to be about...
Apologies for stepping into what appears to be a huge pile of excrement but - - - - questions from a noob!
I have been turning ideas every which way but as soon as I want to have a router (or something functioning as one) where I can have GBit optical fiber (or faster) input I'm quite stymied!
I can put together something with a mobo (slightly older and something like a i5-3470 and the parts (mostly used) are going to run me $200 USD (pardon if I'm not working to the penny but shipping etc there will likely be added charges). I can find a refurbished box for around the low $300 CAN line or just a little more in dollars but its been a complete system for a while so likely better longevity (my guess - - - please). So if I add a 16 GB or thereabouts SSD (or equivalent) and then 2 single port optical GBit
PCI boards I'm upping my costs by about $100 usd. So totals around $325 to 350 usd to maybe $50 more than that.
Well - - - - the Macchiatobin single shot comes with 2 - 10 GBit optical and ready to rock for around $310 usd (shipping - - - could drive that up an easy $20 as many of these companies use their shipping as a serious profit center!). So I'm getting a lower power consumption setup for about the same $$$.
So how does the routing processing speed compare between the Marvel 8040 running at 1.6 GHz and 4 cores compared to a i5-3470T running on 2 cores (I think that's at about 3.2 GHz or so but don't quote me on that - - wry smile!)?
I'm seeing that over the long haul power consumption is going to favor the Macchiatobin easily.
If more processing power is needed for another $100 (or so) a double shot then ups the 8040 to 2.0 GHz (if that's needed).
So - - - - over to you'll (you're the ones with the experience at the behind the bezel stuff (not me for sure!)) - - - - - suggestions - - - - criticisms - - - - bricks bats or flowers - - - (just something - - - please).
(If this is something that should have its own topic - - - please advise - - - - will shift it.)
