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.
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!!
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.
I check.... Seems like there are no switch led control support in current mvsw driver.
I will check SDK about the possibility to add it.
swconfig dev switch0 help switch0: 10.mvsw61xx(MV88E6352), ports: 7 (cpu @ 5), vlans: 64 --switch Attribute 1 (int): enable_vlan (Enable 802.1q VLAN support) Attribute 2 (int): enable_mirror_rx (Enable mirroring of RX packets) Attribute 3 (int): enable_mirror_tx (Enable mirroring of TX packets) Attribute 4 (int): mirror_monitor_port (Mirror monitor port) Attribute 5 (int): mirror_source_port (Mirror source port) Attribute 6 (none): apply (Activate changes in the hardware) Attribute 7 (none): reset (Reset the switch) --vlan Attribute 1 (int): port_based (Use port-based (non-802.1q) VLAN only) Attribute 2 (int): vid (Get/set VLAN ID) Attribute 3 (ports): ports (VLAN port mapping) --port Attribute 1 (string): mask (Port-based VLAN mask) Attribute 2 (int): qmode (802.1q mode: 0=off/1=fallback/2=check/3=secure) Attribute 3 (int): pvid (Primary VLAN ID) Attribute 4 (unknown): link (Get port link information)
What's up guys? I'm having some weird issues with the latest Davidc build. Everything was done as a clean install coming. from factory Linksys firmware. After a few hours, wifi seems to completely break. Also, I am unable to gain access to the webui via any method. I have to manually boot the other partition, and do a reset on stock to get the router back to functioning. Have any of you guys experienced anything like this? Any ideas that I could try? This is happening on a WRT3200ACM. 80MHz channels enabled and ac only on 5 GHz.
The wifi issue described sounds like a DFS channel is being used. If that is the case, stick with the first 4 channels in the spectrum OR the last 4 channels in the spectrum, and that will avoid the DFS issue.
Hey bud. Is there a build that doesn’t have this issue present? I could manage if not. I’ll try the first couple of channels for 5 GHz and 2.4.
Because of the way the firmware (Associated with Wifi driver) has been programmed to detect radar, you may or may not have an issue with DFS channels. This issue goes back to the 1900ac v1 days (Since the beginning). Over the years there has been much debate on how Linksys interpreted the FCC requirement to vacate a DFS frequency. Currently, it appears almost any competing signal, on the frequency, will cause an immediate vacation of the DFS channel hence why you may or may not have an issue.
I have observed, using 40Mhz width can increase ones chances of actually holding on to a DFS channel over a 80Mhz width.
Well, I'm about to do a reinstall and we'll see how it goes. I'll make sure to use either the first 4 or the last 4 channels.
Thanks. This is beyond my expertise so any help is greatly appreciated.
FWIW: I get the exact same output on my WRT3200ACM to yours for the "swconfig dev switch0 help" command.
For my WRT1900AC V1 the only difference is:
What issues did you have with Rosy? I've been trying to report issues to their GitHub and personally (IMHO) think it's the best looking of the themes officially available. Just trying to do my part to identify, report, and squash bugs.
I didn't find datasheet for both of them, but seems like the driver from 6100-series as well.
I check 6000-series datasheets (and Linksys firmware confirms it) - there are some registers for LED control (btw, both 1900 and 3200 have 2 leds per port), so i try to play with it then have a little more free time.
I can't remember exactly right now but I will try to reproduce the issue.
Rosy does look good, no doubt about it.