Can we get this into the main?
1 Like
Did you manage to find out?
I'm still trying to understand from where can I download the Sysupgrade image to update the router.
Pesa i believe uploads the 'stable' (non-testing) versions here .. the latest one at the time of this post being r4.5.29.rss.mtk version uploaded on 2025-03-17 - the sysupgrade link is here - good luck!
3 Likes
upload: 2025-04-19_r29721-5111451803_next-r4.5.34.rss.mtk
hostapd: update to 2025.04.18
mt76: update to 2025.04.11
mac80211: codel param fix
mtk-eth: backport Mediatek SoC EEE support
mtk-eth: change QDMA ring size
mtk-eth: correct max weight of queue on 100mbs
kernel: update to 6.6.87
sync with owrt master 2025.04.18
12 Likes
Congrats on another fine branch/release, @pesa1234! I've been testing your 4.5.34 branch for a while now and it's been very good. 
For anyone who builds their own image based on Pesa's branches, would there be interest and willingness in trying a kernel config patch I've been testing with as well? I have been testing with a tickless-idle, fully preemptive kernel with a timer of 1000HZ. There are a few other config changes as well, but it's bootable and has been very stable for me.
If interested, I could drop the patch somewhere for those brave souls who are willing to try some kernel tweaks. 
For image builders who enjoy testing/tuning, here's the patch I referred to above:
2 Likes
Would you describe the benefit for the common man? Sounds intriguing but what to expect from the patch?
1 Like
Sure! My goal in setting out to test these kernel mods was to try and further reduce latency and jitter--essentially "squeezing the sponge" for all it's worth.
The OpenWrt interrupt timer default is 100HZ. That allows the CPU to execute on a process for up to 10ms before the next timer tick. That's good for overall throughput, but by increasing the interrupt timer to 1000HZ, this reduces the CPU execution time down to 1ms before the next tick.
So by increasing the interrupt timer rate, we limit the amount of time a process can execute on the CPU before the next interrupt, which lowers throughput somewhat. However, it allows for higher priority interrupts to be processed at a 1ms resolution instead of having to wait up to an additional 9ms before they can be handled. My hope is that this allows for the NIC and wireless radio IRQs to get processed more quickly, thus reducing latency & jitter at the network level.
As for preemption, here's a snippet from an Ubuntu blog* about their low-latency images. It explains it better than I can do:
Enabling CONFIG_PREEMPT reduces the kernel latency by making low-priority processes involuntarily preempt themselves. Preemption is disabled only at critical locations where the kernel must protect data from concurrency.
Finally, the tickless-idle mode of operation is meant to be somewhat of a mitigating factor for the loss in throughput at the 1000HZ interrupt timer. It is also known for power savings, though that was not necessarily my primary goal.
The way it works is a little more involved to explain, but let me give it a shot. Every CPU core has its own attribute known as nr_running. It keeps count of the number of running processes on the core. Without a tickless-idle mode of operation, the interrupt timer (which is every 1ms at 1000HZ setting) would fire on each core, thus bringing it out of idle, regardless of whether nr_running is actually zero. This is not efficient, obviously.
So with the tickless-idle mode, if nr_running <= 1 for a given CPU core, then the core runs "tickless" and is not brought out of idle or otherwise interrupted if it is busy with a single process. However, once nr_running >= 2, the core returns to a "tick" mode at 1ms (1000HZ) until such a time as nr_running <= 1 again.
Hopefully this helps explain the intent in my little experiment. FWIW, I make no claims to be a kernel expert. Just been researching this for a while and finally got around to giving it a try myself.
*Ubuntu References:
https://ubuntu.com/blog/industrial-embedded-systems
https://ubuntu.com/blog/industrial-embedded-systems-ii
9 Likes
I want to test it, but I have no idea how to build a firmware with those parameters. Do you have some prebuilt images or maybe you can share your observations how these tweaks impacts latency and jitter in your environment.
2 Likes
Hello @pesa1234
I want to switch from GL.iNET old version of OWRT to a newest one.
Your build should be well indicated to what I want (best bandwidth for WAN, LAN and WiFi.
But as @sisumara I wonder how to install your build without compiling the whole stuff.
Do the .bin here can be installed ? And how to ?
I also have a question about the package available. Do your build use the OpenWRT package list ? Or do it use your custom repository?
Hello, and welcome! I don't have any plans to produce images for public consumption at this time. I build on-top of @pesa1234's branches and don't want to add any confusion for those who are already in the habit of testing the builds produced by Pesa.
My hope is that those who are comfortable with building their own images can test the kernel changes I've proposed and report their findings (good or bad) to the community here. If the changes are solid and worthwhile, then hopefully @pesa1234 would consider introducing them into the community (public) releases.
Hope that makes sense!
1 Like
See if this helps:
And:
/etc/apk/repositories.d/distfeeds.list
https://downloads.openwrt.org/snapshots/2025-04-19_r29721-5111451803_next-r4.5.34.rss.mtk/targets/mediatek/filogic/packages/packages.adb
https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/packages.adb
https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/packages.adb
https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/packages/packages.adb
https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/routing/packages.adb
https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/video/packages.adb
Hey, I am kind of new to this... maybe this is a bug but I have set up my MT6000 with pesk's latest build and I noticed if I run from terminal "apk upgrade" which updates all installed packages, it will blank out on the "advanced" tab WED and HQoS. I reinstalled from scratch once because I had noticed this and on the 2nd time this happened again and I think that is what caused it.
Is the protocol that I am supposed to leave everything preinstalled alone and just update if there is a new sysupgrade release or is this unintentional?
If I'm not mistaken, there's a warning that upgrading via opkg can mess up the whole system.
Hi
I'm on stable 24.10.1 and want to move to pesa latest release, is it this simple to download bin and flash from luci?
If you upgrade apk or previously opkg it happens.
@immi803 yes.
1 Like
Sir easy to upgrade to your build, only concern is usb connected at 2 and cross checked your advanced settings and force to 2.0 is off but nothing helps for it to be detected as usb 3 and uas which was the case in stable 24.10.1
root@OpenWrt:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.87 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 1d5c:5011 Fresco Logic, Inc. USB2.0 Hub
Bus 001 Device 003: ID 0bda:9210 Realtek RTL9210B
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.87 xhci-hcd xHCI Host Controller
root@OpenWrt:~# lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/2p, 480M |__ Port 002: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 480M
|__ Port 002: Dev 003, If 0, Class=[unknown], Driver=usb-storage, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
root@OpenWrt:~#
1 Like
Logs if this can help, you can see adv log , set to 3.0 but lsusb -t says it differently
root@OpenWrt:~# logread -e usb
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.067671] usbcore: registered new interface driver usbfs
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.073215] usbcore: registered new interface driver hub
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.078539] usbcore: registered new device driver usb
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.099974] xhci-mtk 11200000.usb: xHCI Host Controller
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.105216] xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 1
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.115684] xhci-mtk 11200000.usb: hcc params 0x01403f99 hci version 0x110 quirks 0x0000000000200010
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.124834] xhci-mtk 11200000.usb: irq 132, io mem 0x11200000
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.130636] xhci-mtk 11200000.usb: xHCI Host Controller
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.135847] xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 2
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.143243] xhci-mtk 11200000.usb: Host supports USB 3.2 Enhanced SuperSpeed
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.158681] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.179466] usbcore: registered new interface driver usb-storage
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.186283] usbcore: registered new interface driver uas Wed Apr 23 03:18:17 2025 kern.info kernel: [ 3.620047] usb 1-2: new high-speed USB device number 2 using xhci-mtk
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 4.370032] usb 1-2.2: new high-speed USB device number 3 using xhci-mtk
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 4.533912] usb-storage 1-2.2:1.0: USB Mass Storage device detected
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 4.540418] scsi host0: usb-storage 1-2.2:1.0
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.044346] usbcore: registered new interface driver ums-alauda
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.051254] usbcore: registered new interface driver ums-cypress
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.058031] usbcore: registered new interface driver ums-datafab
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.065064] usbcore: registered new interface driver ums-freecom
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.071874] usbcore: registered new interface driver ums-isd200
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.078612] usbcore: registered new interface driver ums-jumpshot
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.085549] usbcore: registered new interface driver ums-karma
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.095058] usbcore: registered new interface driver ums-sddr09
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.101939] usbcore: registered new interface driver ums-sddr55
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.108693] usbcore: registered new interface driver ums-usbat
root@OpenWrt:~# logread -e sda
Wed Apr 23 03:18:17 2025 kern.notice kernel: [ 5.963767] sd 0:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB)
Wed Apr 23 03:18:17 2025 kern.notice kernel: [ 5.971893] sd 0:0:0:0: [sda] Write Protect is off
Wed Apr 23 03:18:17 2025 kern.debug kernel: [ 5.976668] sd 0:0:0:0: [sda] Mode Sense: 37 00 00 08
Wed Apr 23 03:18:17 2025 kern.notice kernel: [ 5.982148] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 5.996766] sda: sda1
Wed Apr 23 03:18:17 2025 kern.notice kernel: [ 5.999316] sd 0:0:0:0: [sda] Attached SCSI disk
Wed Apr 23 03:18:17 2025 kern.notice kernel: [ 9.499645] XFS (sda1): Mounting V5 Filesystem 2949e5dd-f0b8-4444-8ddb-6c5367777883
Wed Apr 23 03:18:17 2025 kern.info kernel: [ 9.570128] XFS (sda1): Ending clean mount
Wed Apr 23 03:18:20 2025 daemon.info aria2: Please make sure user 'aria2' has write access to download dir: /mnt/sda1/My_Folder/Aria2
root@OpenWrt:~#
adv-log: USB Speed set to 3.0
Another thing after some reading here, i want to setup ftp instead of ksmbd and installed block mount, could this can be reason as you may have setup auto mount with ksmbd, here's my fstab after block mount install
root@OpenWrt:~# cat /etc/config/fstab
config global
option anon_swap '0'
option anon_mount '0'
option auto_swap '1'
option auto_mount '1'
option delay_root '5'
option check_fs '0'
config mount
option target '/overlay'
option uuid '196199d4-1dd2-11b2-b6d4-9483c4a353e0'
option enabled '0'
config mount
option target '/rom'
option uuid '539ed084-5404f168-e1d9e124-6b8d432d'
option enabled '0'
config mount
option target '/mnt/sda1'
option uuid '2949e5dd-f0b8-4444-8ddb-6c5367777883'
option enabled '1'
option fstype 'xfs'
root@OpenWrt:~#
Might want to break this out into a separate thread as a fork of pesa's build.
FWIW - the whole tickless/PREMPT thing is a bit of a hot potato as there have been discussions in the past about this very thing.
I appreciate the feedback, but I'm not sure I want to break it out into a separate thread as I've seen some of the past "discussion" around tickless/preempt. There are those who are destined to hate on it for the sake of arguing, or just because it's different/"new".
The community that is trying Pesa's builds seems to be pretty open to trying new things. I was just hoping to garner some initial interest here and get some quantitative data for which to start having more serious discussions about the merits of such kernel updates.
2 Likes