Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds


root@TTrollstation:/sys/class/leds# ls
mmc0::                      pca963x:0:68:15             pca963x:rango:white:usb2    rango:white:sata
pca963x:0:68:10             pca963x:0:68:2              pca963x:rango:white:usb3_1  rango:white:wlan_2g
pca963x:0:68:11             pca963x:0:68:3              pca963x:rango:white:usb3_2  rango:white:wlan_5g
pca963x:0:68:12             pca963x:0:68:4              pca963x:rango:white:wan
pca963x:0:68:13             pca963x:rango:amber:wan     pca963x:rango:white:wps
pca963x:0:68:14             pca963x:rango:amber:wps     rango:white:power

It's my 3200. I'm a bit away from it last days, but check pca's leds then return back.

PS: Did you read the first link i send? Don't use trigger (firmware will enable it again), use brightness instead.

100Hz as found in the config files under ./target/linux/generic/config-*. Mvebu inherits this value (however, some chipsets override this setting to 250Hz, like Lantiq).

Changing this might not be as useful as you think given that CONFIG_SCHED_HRTICK and CONFIG_HIGH_RES_TIMERS are enabled in the generic profile (and MVEBU inherits these values too). This means that only schedule_timeout() or anything else that uses jiffies for time accounting are the only things really affected by changing this value

Thanks! I had a hunch it was but was unsure.

I think I tried all suggestions without success but which one do you mean?

BTW the LED files in "/sys/class/leds" are symbolic links to various locations:

root@FIREBASEROUTER:/sys/class/leds# ls -la
drwxr-xr-x    2 root     root             0 Jan  1  1970 .
drwxr-xr-x   41 root     root             0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root             0 Jan  1  1970 mmc0:: -> ../../devices/platform/soc/soc:internal-regs/f10d8000.sdhci/leds/mmc0::
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:10 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:10
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:11 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:11
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:12 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:12
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:13 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:13
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:14 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:14
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:15 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:15
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:2 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:2
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:3 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:3
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:0:68:4 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:0:68:4
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:amber:wan -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:amber:wan
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:amber:wps -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:amber:wps
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:white:usb2 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:white:usb2
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:white:usb3_1 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:white:usb3_1
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:white:usb3_2 -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:white:usb3_2
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:white:wan -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:white:wan
lrwxrwxrwx    1 root     root             0 Jan  1  1970 pca963x:rango:white:wps -> ../../devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/0-0068/leds/pca963x:rango:white:wps
lrwxrwxrwx    1 root     root             0 Jan  1  1970 rango:white:power -> ../../devices/platform/gpio-leds/leds/rango:white:power
lrwxrwxrwx    1 root     root             0 Jan  1  1970 rango:white:sata -> ../../devices/platform/gpio-leds/leds/rango:white:sata
lrwxrwxrwx    1 root     root             0 Jan  1  1970 rango:white:wlan_2g -> ../../devices/platform/gpio-leds/leds/rango:white:wlan_2g
lrwxrwxrwx    1 root     root             0 Jan  1  1970 rango:white:wlan_5g -> ../../devices/platform/gpio-leds/leds/rango:white:wlan_5g
1 Like

says " The 1900ac has the cpu idle (Reboots on latest kernels) issue resolved"

I have been having reboot issues for a little while now (WRT1900AC - Random reboots) and just wondering if that comment could be the cause.

im running 18.06.01 openwrt on wrt1900ac (mamba) with the latest mwlwifi drivers (from: https://github.com/eduperez/mwlwifi_LEDE/releases) would/could it apply?

on that website it links to an img file, to flash lede, is there any equivalent patch for openwrt?

Not that I'm aware.

18.06.01 is from Fri Aug 17 2018. I recommend going to 18.06.02 OR download and flash the image from the davidc502 site. Ether of those are patched to resolve the reboot issue.


Has anyone tested at 1000hz kernel timer? Specifically refering to sqm for any relatable differences in performance on the 3200ACM...

It's probably best if you start a new topic instead of hijacking this one since kernel timer frequencies are done at compile time and I don't think @davidc502 or his users will or have had changed MVEBU's kconfigs.

I will say this though, I've tried running these kernel configurations on my 1900ACSv2:

  1. PREEMPT_NONE; HZ=100 - Ethernet has tight latencies with SQM but wifi will have a max latency of +20-40ms from the average (depending on number of clients connected).
  2. PREEMPT_FULL; HZ = 100 - Ethernet displays the same behaviors as standard config but wifi is incredibly jittery. I was experiencing quite a bit of packet loss and the max latency would randomly go up to the +100ms (for either upload/download/idle). Other tasks running on the device could have probably caused some important wireless/bufferbloat related irqs to pause.
  3. PREEMPT_VOLUNTARY; HZ = 250 - Again, ethernet displays the same behavior as in the default standard configuration. Wifi's max latencies is around +10-20ms from average (even with tens of clients).
  4. PREEMPT_VOLUNTARY; HZ = 1000 - Same behavior as (3).

Testing was mostly done with just dslreports, so take it all with a grain of salt. WAN speed at 30/30Mbps. Wireless tests were conducted from a distance of 2.4GHz and 5GHz at 10-15m away with an RSSI of -58 to -62 (noise -90) on a mid-2015 rMBP. I couldn't really be bothered to setup iperf on two machines. I didn't try PREEMPT_FULL; HZ = 1000 because that would have probably sacrificed throughput quite a lot (and may have been a bit unstable). So with this really crude method, ethernet latencies aren't affected, but wifi could be. However, I'd hesitate to state any conclusion given n=1 and a lack of a complete and proper testing tool/methodology.

Also, apologies to anyone reading this as it's unrelated to @davidc502's build.


@davidc502 : how come you use this config:

All Linksys WRT has built in hardware FPU, i never used that (only on my D-LINK D860L B1 - which needs FPU emulator), so how come you enable this?

(I found it in you config.seed file)

If it was not built in (#CONFIG_KERNEL_MIPS_FPU_EMULATOR is not set) it would not worked at with NodeJs 11 (based on https://github.com/nxhack/openwrt-node-packages) and it works.

It is ARM, so i guess it is not used in the build?

Had been looking for a list of packages you added but never asked... Is there any benefit to us removing packages we don't need from your builds once installed? For example, I have the WRT32X and don't need all the mwlwifi firmwares you have, just the 8964. Or is the extra stuff not hurting anything being there?Thanks.

If you need the space, remove them. Otherwise.... eh :slight_smile:

I want to say thank you for your time as I don't have the any lately (70+ hours a week since Oct 2018). It's not hijacking; it pertains to the performance of the 3200acm. I know sqm is a good stress test and was wondering if anyone has seen better results overall. I don't per say have a need to increase timer resolutions, just curious. In essence, it appears leaving the default at 10ms is a good choice. One day when I get back to a normal schedule I'll be able to setup a lab but for now I have to rely on others for testing.

Sorry if I came off as harsh with the 'hi-jacking' comment. I didn't mean to. That 70+ hours work week sounds insane. I'd be glad to see your test results once your work load lightens up!

I'd actually really like to see some more controlled experiments on what effect voluntary or full preemption does on the consistency of the latency on WiFi (especially with mwlwifi) with SQM under higher WAN (or LAN!) speeds. Then maybe another test on 100Hz v. 1000Hz tick rate (to see the tradeoffs between latency consistency v. throughput), and subsequently the combination of various preemption levels and tick rate. I am actually still not sure if this even applies anymore (or if it even applies to routers!):

...default Linux kernels are often compiled with HZ=250 (or even lower), causing burstyness and non-uniform delivery of packets; building your kernels at HZ=1000 will reduce this effect...

For now, there is historical data (but mostly conjecture) on the r7800 build thread by @hnyman and this thread. User @shm0 probably has more solid evidence than I do, and his/her data is much more relevant to us given that he/she owns a WRT1200AC (and I think he/she has also managed to overclock it to 1.6GHz - up from 1.33GHz!).

This is hardset to 100Hz for unknown reasons (?)

I did suggest that it's being removed and we stick to what upstream suggests per arch instead

Thank you once again for your hard work. In case you did not notice you have written "NEW 2/09/2018 New builds have been release and are ready for download." Shouldn't it be 2/09/2019. Thanks.

:+1: Thanks for reading. It has now been changed.

I'm on r9287 since yesteday and everything works fine over here. The rosy theme was lil bit buggy so I had to change to bootstrap to configure some things within the GUI. I think bootstrap should be the default theme atm...
Thanks for your work david!! :slight_smile:

I was hopeful that Rosy would be maintained, but it looks like they only work on issues they want to work on leaving other issues to die on the vine.

With that said I may go back to bootstrap.


For some who might want to try luci-theme-bootstrap, all that needs to be done is to remove luci-theme-rosy. Bootstrap is already installed by default.

You can also change the theme under 'System > Language and Style' without removing rosy but for now I don't see any reason to keep the rosy theme if it's buggy.
Btw, luci-theme-material is also working fine for me and I always used this theme in the past with your builds.