@phinn you noticed a throughput difference between the two packet steering scripts? With my 1gb docsis cable lines - they both allowed max throughput. What I did notice was increased jitter with “all CPU” vs standard… leading me to believe that the new script was acting as intended, and minimizing latency.
1 Like
Yea increased jitter makes sense given what its doing and if it doesn't need to spread things out to the cores it can hurt slightly. Same goes for irqbalance, which on this target mostly just spends time rescheduling interrupts. I found the difference to be very small on my tests. Enabling it is the main difference in performance.
A little background here -- I've been using OpenWrt for five years now, mostly on a GL-iNet GL-B1300. My connection is 1 Gb Verizon Fios. The B1300 was a little underpowered for that connection and when the front lights stopped working, I decided to upgrade. I used my old Eero 6 Pro for a while and got used to the consistent 600 Mbps download and upload speeds, but missed the flexibility of OpenWrt and figured the GL-iNet MT6000 would be a good replacement. It's mostly great -- I get better download speeds than the Eero, usually in the 700 Mbps range, but the upload speed is abysmal. I'm lucky if it's over 100 Mbps. I've done many searches and encountered people with the same problem, but have not found a solution yet.
- I'm always on a 5 GHz channel when I test.
- Packet steering is enabled for all CPUs.
- Steering flows (RPS) are at the suggested setting of 128.
- Hardware offloading is on (also tried software offloading).
- Irqbalance is on.
- I tried going back to the GL-iNet firmware (could this be a MediaTek thing?).
Nothing fixes the upload speeds (except swapping the Eero back in). I'm beginning to think this is something I'll have to live with. Thoughts?
Do you have a link to those benchmarks? Checking the wiki it just has the recommendations, but not the data or plots to back up the recommendation.
Do you tried Hardware Offloading off and SQM?
I've tried hardware and software offloading. I have not tried SQM, mainly because it is turned off on my Eero, which works fine. But I will go ahead and give it a shot.
No luck with SQM 
That sucks, you may have something else going on 
That is odd, I'm maxing out my 500/500 connection with my Flint 2. Have you checked the "stupid" things?
- Does the cable make a difference?
- What ethernet up link speed does the Flint 2 think it has?
- Try swapping the WAN and 2.5G LAN port and see if your WAN port is physically faulty.
- Try swapping the WAN and one of the 1G LAN ports?
1 Like
Well this is interesting -- Since the Eero works fine, I ran an ethernet cable from the Eero to the MT6000 WAN port and now the MT6000 is getting full upload speeds. This is not a long-term solution, but it does seem to indicate that there are communication issues between the MT6000 and the Fios ONT box. Hopefully there is some setting I can change on the MT6000.
That is a step forward on the troubleshooting path. You have now isolated it to either the cable or the communication between the devices. It is unlikely that you have faulty hardware (apart from possibly the cable).
One thing to keep in mind is that 2.5G ethernet can be finicky, not all devices react well to the other end trying to negotiate that speed, or so I have heard (I haven't had any issues myself). So you could try reassigning which port is the WAN port on the Flint 2 to a 1 GB port. For this you likely need to make use of VLANs.
There should probably also be a way to cap the speed to 1G, preventing 2.5G from being attempted at all. Probably this is possible with ethtool manually as a test at least. Some reading of the manual page will be needed.
1 Like
@richardhd You could install ethtool if you don't already have it and try the following:
ethtool -s eth1 speed 1000 duplex full autoneg on
If eth1 isn't the interface you're connecting to your ONT, then adjust the command as needed.
This would force the interface to 1Gbps (obviously full duplex since half duplex doesn't exist with 1Gbps) and still leave auto-negotiation on since some network devices are finicky if one side is set to auto-negotiate and the other not.
You could try that and see if it resolves your issue. If so, drop that ethtool command into your /etc/rc.local file so it survives reboots. Better yet would be to add it into a hotplug script so it sets that configuration whenever your "WAN" interface on your MT6000 comes up. But anyway, that's a day-2 thing if this does fix your situation.
If that does not fix things for you, you might as well try...
ethtool -s eth1 speed 1000 duplex full autoneg off
...just in case auto-negotiation isn't playing nicely and is causing you this headache.
Let us know how this goes if you try it.
1 Like
the ethernet cable is of great importance! I have a lot of bugs with it in my experience! you check with a tester - all 8 wires are OK! But the speed is only 100 Mbps, or absent. all these patch cords are made of multi-core wire for softness and flexibility, but this leads to poor contact between the wire and the RG45 connector. Also, low-quality RG45 connectors can be the cause of low speed.
2 Likes
Check for firmware upgrade for you ont box. I had similar issues with leox ont box and it was resolved by the manufacturer by upgrading the firmware.
Thanks for the advice, but still no luck. This is what ethtool tells me:
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Transmit-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Again, my Eero has no problem with upload speed using the same ONT and cable.
Out of curiosity, could you run ethtool --show-eee eth1 and drop your output in a reply?
PSA: If you want working ipv6 on an android phone turn on "multicast_to_unicast"
###### Set multicast to unicast - IPv6 workaround for low power devices (WIFI) ######
uci set wireless.default_radio0.multicast_to_unicast_all='1'
uci set wireless.default_radio1.multicast_to_unicast_all='1'
uci commit
Android phones tend to lose RA messages when using multicast in WiFi. Pixel devices are notorious for this problem with their wi-fi chip sleeping for 1.11 seconds.
A good detailed read on where I found the solution: https://mailarchive.ietf.org/arch/msg/ipv6/QgHnYoT8-ur4epJHUNflrsh7sA4/
Google bug tracker: https://issuetracker.google.com/issues/241959699?pli=1
I think anyone using dual stack network at home with an android device should do this. It will keep the ipv6 connection overnight. Otherwise, you get ~5-6 hours before the ipv6 route goes away. Your phone will still display ipv6 address but no ipv6 packets will be sent.
Imagine how many users in the world don't even know about the problem.. How much of the internet traffic could be ipv6 but isn't because of power saving features geared towards ipv4.
We should make unicast=1 default for our router if most users are using ipv6.
2 Likes
root@OpenWrt:~# ethtool --show-eee eth1
Cannot get EEE settings: Not supported
1 Like
Glad to hear this is a working solution for you. I have to admit, however, this is a setting I used to have enabled all the time prior to my MT6000s. But several of us have had some issues (see here and here) with it enabled. While many of the original issues have been addressed with some driver/firmware updates, I found in my use-cases it isn't causing me much headache to have it disabled in my primarily Apple ecosystem.
Anyway, just a general heads-up that it has been problematic for some in the past, so if one turns it on and starts hitting issues, I would be quick to suspect it 
When and where it works, use it. 
3 Likes
Another thought to try, unless you have already and I missed it (apologies if so!), would be to plug the eth1 interface from your MT6000 to a gigabit port on a computer you have and run:
- iPerf3 in server mode on the MT6000 <---> iPerf3 in client mode on the computer
- iPerf3 in client mode on the MT6000 <---> iPerf3 in server mode on the computer
(If you need any assistance with the iPerf3 commands, let me know)
But check the bandwidth both directions (and run a bi-directional iPerf test if you desire) and see what you see. If you hit any indications of significant slowness in either direction, try a different ethernet port on your MT6000 just to make sure your computer is capable of doing a gigabit iPerf3 test.
Would be interesting to hear your results of this one.
P.S. Could you remind us of what OpenWrt version you're running? 24.10? Snapshot? Something else?