GL.iNET Flint 2 (GL-MT6000) discussions

SiXX · 2024-04-15T05:38:23.216Z

No - WED remains enabled after an update, assuming you had it enabled prior & saved settings when updating.

dnd · 2024-04-15T07:30:08.531Z

There seems to be an issue with the new packet steering script:

This recent commit broke packet steering: daemon.notice procd: /etc/rc.d/S25packet_steering: Type error: left-hand side is not a function daemon.notice procd: /etc/rc.d/S25packet_steering: In task_name(), file /usr/libexec/network/packet-steering.uc, line 30, byte 29: daemon.notice procd: /etc/rc.d/S25packet_steering: called from anonymous function (/usr/libexec/network/packet-steering.uc:152:26) daemon.notice procd: /etc/rc.d/S25packet_steering: daemon.notice procd: /etc/rc.d/S25packet_steer…

anom3 · 2024-04-15T14:57:02.645Z

@SiXX

btw, i just did some testing... i am seeing some benefit having packet steering enabled even in dumb ap mode.

generally, even with it disabled, bridging through the two 2.5gbe ports maxes out the link speed. or very very close to anyways.

but going mt6000 TO client (via 2.5gbe port), without packet steering i max out at about 2.1gbe... with it enabled it maxes out at 2.5gbe.

consistently btw, no doubts about it. i just did 6 or so reboots on / off testing clean boots. same result every time.

iperf3 server running on client connected via one of the 2.5gbe ports (lan1 if it makes any difference)

iperf3 client running on mt6000 to above server, "-R" so "sending"

2.1 with packet steering disabled
2.5 with packet steering enabled

so looks like there is some benefit to enabling packet steering.even in dumb ap

caveat : i am running bridger + wed etc etc, so maybe it is altering the traffic in a way that allows for packet steering to have some sort of effect. thats all beyond me though

SiXX · 2024-04-15T15:09:05.112Z

Theoretical is just that... theoretical. Nothing beats real world testing & results though - so kudos to you. Provided it doesn't introduce any instabilities in your setup, sounds like ON is the way to go.

_FailSafe · 2024-04-15T15:20:40.791Z

Heads-up! Felix added this commit for bridger that fixes several issues including this long-standing one: https://github.com/nbd168/bridger/issues/3

anom3 · 2024-04-15T15:21:19.250Z

btw tomorrows snap shot should include:

a) 2 changes to bridger
b) 1 change to the packet steering script

i checked, todays does not have the commits yet.

anom3 · 2024-04-15T15:22:18.023Z

haha beat me to it!

its not in the generated snapshots yet, assuming they compile daily, will be tomorrow(?).

phinn · 2024-04-15T15:31:11.409Z

Yes tomorrow. @anom3 I wouldn't test packet steering until at least tomorrow either, if not later this week (in case nbd finds any bugs in his new script) the new script looks like it works with rps and will behave quite a bit differently (i'm not an expert, but it looks to function more the way it's supposed to). I'm looking forward to a snapshot maybe this weekend. More excited about upcoming 6.6 though

foggygray · 2024-04-15T19:26:34.408Z

That’ll be interesting to try out. I usually update when there’s a new kernel update but will hold off until packet steering works ok.

_FailSafe · 2024-04-15T20:18:01.479Z

phinn:

I wouldn't test packet steering until at least tomorrow either, if not later this week (in case nbd finds any bugs in his new script)

I am running with the updated script on my MT6000s without any syntax issues at this point. (As opposed to issue called out here)

Here's how it appears to shake out on my MT6000s:

root@AP-2:~# /etc/init.d/packet_steering restart
pid 513's current affinity list: 0
pid 513's new affinity list: 0
pid 514's current affinity list: 0
pid 514's new affinity list: 0
pid 983's current affinity list: 3
pid 983's new affinity list: 3

Whereas:

root@AP-2:~# ps -aux | grep -e 513 -e 514 -e 983
root       513  0.0  0.0      0     0 ?        S    15:36   0:02 [napi/mtk_eth-5]
root       514  0.0  0.0      0     0 ?        S    15:36   0:03 [napi/mtk_eth-6]
root       983  0.0  0.0      0     0 ?        S    15:36   0:12 [mt76-tx phy0]

Delphius · 2024-04-15T21:58:20.067Z

I saw you mentioning kernel 6.6 a few times already. What makes you so excited about it? What is expected to change?
just curious...

apccv · 2024-04-16T00:18:57.343Z

Not sure either... but... my 0.02

IMO there are two major things in kernel 6.6 that may have a measurable impact here:

new scheduler: EEVDF replaces CFS. This is the kernel logic that allocates time to running processes. Should result in better kernel task management so less process latency. Now, as for that translating tangibly to network latency or throughput, it may be a stretch.
In kernel SMB server. This could mean much more efficient file sharing for anyone using the router as a NAS. Kernel size can be a problem, so might not be included by default in OpenWrt images.

Then we have updates to drivers all over but at this point I would imagine everything is being backported to 6.1.

New is always exciting, regardless. A lot of work goes into every new LTS kernel. Hopefully it results in measurable improvements.

dnd · 2024-04-16T06:48:24.059Z

Is this kind of benchmark any good for comparing the performance of the kernel?

Please run iperf3 -c 127.0.0.1 and post results here to make router database Hardware Questions and Recommendations

I was thinking it might be interesting to post the results of raw internal iperf3 tests which are run on whatever router you use while using yourself as the client and server. Please note what version of OpenWRt you are running. The way to do this is to ssh into your OpenWRT device and run: opkg update && opkg install iperf3 Once that is all done then run this next: iperf3 -s -D && iperf3 -c 127.0.0.1 I'll go first, with my Raspberry pi 4b hardware version 1.4 (the latest as of oct 2021) o…

There are too few data points yet for the MT6000, but it looks like it's a lot faster with kernel 6, than 5.15.

foggygray · 2024-04-16T19:31:33.250Z

Is that packet steering update included in the netifd package or is there something else to be on the lookout for?

_FailSafe · 2024-04-16T19:37:39.921Z

It's part of the netifd update. See this commit: https://github.com/openwrt/openwrt/commit/a205a5734eda4604a19b6cb0f65909ef69730699

foggygray · 2024-04-16T19:40:07.258Z

Thanks! I was just wondering because I didn't see a netifd update on the main snapshot yet.

phinn · 2024-04-16T20:22:42.711Z

Yes those items for sure and others. At a high level it's a celebration that this Linux distro for networking runs the latest LTS kernel.

@_FailSafe and you probably noticed, but there was a bugfix nbd submitted to the script shortly after in netifd as well.

Jack007 · 2024-04-17T09:24:49.226Z

nxhack:

So far it seems stable.

[MAC80211][WiFi6][mt76][Preparation of Filogic 830/820/630/615 MP2.2 external release information]
https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/fa2deacf4d2f409220bb9d713fc4fa5ce14cc494

I tried the new firmware which seems to work fine.
But my son is now complaining that his Xbox only shows moderate NAT (not open). Any change that those two are related?

pesa1234 · 2024-04-17T11:52:01.926Z

No relation, for sure port is not open on your side

marek22k · 2024-04-17T12:27:01.529Z

Hi, I've got the Flint 2 and it's getting quite hot at the bottom. I created a thread about this and was advised to ask here. What could be the reason for this? Is this normal? Can it be harmful to the router?