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
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.
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:
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).
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.
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).
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.
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.
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!).
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.
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!!
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.
Thanks for reading. It has now been changed.