Joined: 08 May 2018 Posts: 14244 Location: Texas, USA
Posted: Mon Feb 10, 2020 16:34 Post subject: New Build 42335: 02-10-2020-r42335
WARNING:DO NOT flash this experimental test build unless you know the risks and recovery methods. Report here to provide important info for developers and users. Always state your hardware model & version, mode (e.g. Repeater) and SPECIFIC build (e.g. netgear-r7000-webflash). Avoid discussions and create a new thread for specific problems or questions as this thread is not for support, and posts may be deleted or moved.
Important: if reporting any issues, provide applicable info (GUI syslog, `dmesg`, `cat /var/log/messages`, etc.)
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
Template example to copy (after "Code:") for posting issues, be sure to include the mode in use (gateway, AP, CB, etc.):
r7800 latency is on par with kong builds, but the cpu usage for sirq on wifi interfaces is still broken and over 3x higher than kong builds and BS k3.18 builds.. if the r7800 was doing nat+qos, it still would be choking at these speeds from not enough cpu free.. keep the latency the same and fix the cpu usage, this will be finally 100% fixed for the first time..
kong r40720m firewall/qos/nat disabled, 5ghz sirq cpu load @ 320mbps:
core0: 15%
core1: 3%
ANY k4.x bs build firewall/qos/nat disabled, 5ghz sirq cpu load @ 320mbps:
core0: 60%
core1: 40%
still forced disabled/broken hostapd syslog output on many routers, but its fixed on r7800..
Linksys EA8500
DD-WRT v3.0-r42335 std (02/10/20)
Linux 4.9.213 #518 SMP Thu Feb 6 03:52:58 +03 2020 armv7l
up 12:31
samba good ...prolly better than previous
WiFi good
unbound good
VLAN good
ovpn server good
HFSC CAKE good
#
Netgear WNDR3700 V4
DD-WRT v3.0-r42335 std (02/10/20)
Linux 3.18.140-d4 #69629 Mon Feb 10 07:24:43 +04 2020 mips
up 12:47
all works ok
EA8500 CLI upgrade from 02-06-2020-r42287 to 02-10-2020-r42335 with no issues.
EDIT: After 9 days uptime my throughput dropped to 2.5Mbit both ways. No strange cpu load or memory usage and restarting httpd did nothing. Reboot and all is well.
Last edited by blkt on Thu Feb 20, 2020 9:49; edited 1 time in total
r7800 latency is on par with kong builds, but the cpu usage for sirq on wifi interfaces is still broken and over 3x higher than kong builds and BS k3.18 builds.. if the r7800 was doing nat+qos, it still would be choking at these speeds from not enough cpu free.. keep the latency the same and fix the cpu usage, this will be finally 100% fixed for the first time..
Yes, CPU spikes way up if you copy a big file (3gb) over WIFI. My router (tp-link TL-WR841ND v8 ) would sometimes crash and reboot in the middle of copying a big file over wifi. I was watching router's cpu usage and network transfer rate on my notebook. When router's CPU starts to go way up, transfer rate drops dramatically from 9MB/s to less than 1MB/s. This has been happening since end of 2018. So I use a working 2018.11.30 build which has linux3.18 and router's cpu doesn't spike up...
All the builds I tried after 2018.11.30 have cpu spike problems...
r7800 latency is on par with kong builds, but the cpu usage for sirq on wifi interfaces is still broken and over 3x higher than kong builds and BS k3.18 builds.. if the r7800 was doing nat+qos, it still would be choking at these speeds from not enough cpu free.. keep the latency the same and fix the cpu usage, this will be finally 100% fixed for the first time..
Yes, CPU spikes way up if you copy a big file (3gb) over WIFI. My router (tp-link TL-WR841ND v8 ) would sometimes crash and reboot in the middle of copying a big file over wifi. I was watching router's cpu usage and network transfer rate on my notebook. When router's CPU starts to go way up, transfer rate drops dramatically from 9MB/s to less than 1MB/s. This has been happening since end of 2018. So I use a working 2018.11.30 build which has linux3.18 and router's cpu doesn't spike up...
All the builds I tried after 2018.11.30 have cpu spike problems...
Thank you for looking into it.
theres little hope.. brainslayer doesnt care and just eyeballs the issue, says "no problem here etc". only one that believed and fixed it, was kong and he quit ddwrt _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Wed Feb 12, 2020 1:37 Post subject:
tatsuya46 wrote:
theres little hope.. brainslayer doesnt care and just eyeballs the issue, says "no problem here etc". only one that believed and fixed it, was kong and he quit ddwrt
Here is my two cents.... If you take a "scientific approach and document the issue in great "scientific" detail of what you're doing, how you're doing it, your settings, etc, and then other users can set up the same way and reproduce the issue, you've done a good job of detailing the issue and BS should be able to reproduce it on his end.
Right now, to be fair, all I see is garbage and complaining and nothing specific....
OK wifi transfer kills the router... is it wifi to wifi, wifi to lan, wifi to usb???? what other settings are set? Q.o.S.? if yeah, what settings?...
See where I am going with this?
The few issues I have raised to BS in a scientific way have been resolved....
Clearly BS can't put his finger on the specific K4.x part of the code that kills cpu... Kong was a debugging Master...just look him up on LinkedIn... Kong must have compared between the two kernels and found it.... the rest is a mystery b/c no one can email him to ask...or if they have...he's not willing to share (seems unlikely to me). Clearly BS wouldn't listen to Kong and German Stubbornness and Pride took over and we all lost....
so, your only hope is to get more scientific about what you're doing to cause the slowness. My best guess is has to do with CPU scaling and that code. _________________ FORUM RULES
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Wed Feb 12, 2020 2:09 Post subject:
msoengineer wrote:
tatsuya46 wrote:
theres little hope.. brainslayer doesnt care and just eyeballs the issue, says "no problem here etc". only one that believed and fixed it, was kong and he quit ddwrt
If you take a "scientific approach and document the issue in great "scientific" detail of what you're doing, how you're doing it, your settings, etc, and then other users can set up the same way and reproduce the issue, you've done a good job of detailing the issue and BS should be able to reproduce it on his end.
been done countless times. BS always reverting 95% of kong's commits when he committed, should illustrate his stance on "i believe nothings wrong, my code is fine, kernel is fine".
yet again.. there is nothing special to do, nvram wipe if u want, change nothing except user/password and enable 80mhz on 5ghz (since default is like auto on 20mhz or something). enable performance governor, observe ludicrous cpu usage over wifi. do the same on kong's latest build. done. note that is while the router is BRIDGED, if one is to add nat/firewall or qos to it, its exponentially worse. dont need to be wan speed, lan to lan tests show it the same way. openwrt is also affected, except kong's, of coarse. stock fw, ofc no issue there, voxel, dont know, that fw wouldnt boot for me.
some claim to see it (and feel it) too, some say they dont have the issue, or dont care, or dont notice it. last BS build to not have this issue, the last k3.18 build. everything that touches the cpu, even softether, is amplified since kernel 4.x landed on this router (BS only).
scaling governor thresholds can get under load performance near = to that of performance, but with the added massive latency (even internal, like the r7800 pinging ITSELF) when its scaled below 1.7ghz. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
