Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sun Jan 07, 2018 19:30 Post subject:
nothing new to say about the build.. qos unchanged still adding latency etc & cpu load is nearly doubled k3.18 at the same speeds etc. bs build httpd crash happy. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Mon Jan 08, 2018 10:18 Post subject:
notice dir-860l a1 on k4.4 has fq_codel memory limit of 32mb, r7800 has 4mb, kong tried 16mb with no difference but would it just need even more? how & why does an inferior unit have a whopping 32mb? _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Tue Jan 09, 2018 8:12 Post subject:
after more testing this k4.x high load and latency isnt just with wan, its local, all over the router..
doing client mode over wifi to another internet line (same modem and provider too) thats 75/7.5, after testing the load with it on ethernet with my line capped at the same speed via qos. while the load is lower, much lower when wan is via client mode instead of ethernet, theres that same horrible latency from qos at the local level to the host router & its not coming from the host, its coming from the r7800. try k3.18 build, latency to host was like 2ms above idle. the throughput is also jittery & abnormally low on wifi too, struggled to even get 75mbps over ac with -55 signal 975M/975M rates (channel doesnt matter).. when i moved ath0 off core 0 to core 1 for interrupts, it easily then flat lined at 75mbps, but the locally generated latency was still there.
this also explained how earlier today, with a dir-862L as wds station over 5ghz to the r7800 with 1300M/1300M rates -50 signal, only gets 200mbps, with as well, extra latency when that speed is reached.. 1300Mbps 3x3:3 ac goes welllll beyond 200mbps goodput. tried r34036 k3.18, sure enough wifi speeds were much higher to the wds station.
something is very wrong with ipq806x + k4.x. i suggest we should experiment with k4.4 to help find where & whats going on with latency & load, cause its not just wan anymore. as its known for a fact k4.4 has qos equal to that of k3.18, at least on other routers. limiting to around kong's wan speed of 45mbps its much harder to see, but its still there, spikes to the host router that just are never there on k3.18. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
The all problems are related to new Kong test builds with new 4.14 kernel from Test folder.
Please use the standard Kong build and you will be happy
http://desipro.de/ddwrt/K3-AC-IPQ806X/?C=N;O=D _________________ Netgear R7800
Joined: 30 Jan 2015 Posts: 676 Location: Texas, USA
Posted: Wed Jan 10, 2018 7:04 Post subject:
faxxe wrote:
What is the expected advantage of this new kernel?
Thank you,faxxe
One promising aspects of the newer kernel is the better driver support.
We have several good routers are not well utilized just because of the crappy drivers. _________________ ASUS GT-BE98 PRO Main: Fiber 5gbps up/down
ASUS AXE16000: AI Mesh node
2 X ASUS RT-AX89X: AI Mesh nodes
QNAP QSW-1208-8C 12-Port 10GbE Switch
XS712T ProSafe 12-Port 10GbE Switch
3 X R9000 DD-WRT Mesh
We are aware of the load issue and I just did some kernel profiling, going to discuss this with BS.
That's great to hear. May I ask what tool(s) you used to profile? Any chance of including perf/bcc-tools/<what you used> by default at least on the test builds?
tatsuya46 wrote:
absolutely, ZERO, currently. its broken, it adds latency, increases cpu load, reduces throughput
I agree those are downsides, but it certainly does have *some* benefits. From my perspective I value the new exploit mitigations[1][2][3][4][5][6][7][8][9][10][11][12], which makes me a bit more comfortable exposing a machine to the internet. Also 4.14 will get more straightforward patches from mainline. For example look at the patches for Meltdown/Spectre, they really have only tested them on 4.14 and 4.9.
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Jan 11, 2018 9:43 Post subject:
for what its worth if it helps or not i found interrupt moderation setting on client nic is affecting cpu load for the first time ever. its affecting eth1 load on core 0, heavy reductions there, with a slight increase on core 1 eth0 wan load but overall load drops.
htb+fq_codel set for 150mbps/15mbps flat
wan interface is set to core 1 as its mandatory currently. rest of interrupts are default.
k4.x interrupt moderation off = 5% free (overall cpu)
k4.x interrupt moderation low = 12% free (overall cpu)
k4.x interrupt moderation med = 21% free (overall cpu)
k4.x interrupt moderation high/extreme = 30% free (overall cpu)
k4.x wifi = 21% free (overall cpu) <-- no interrupt mod control
k3.18 any interrupt moderation setting = 46% free (overall cpu)
k3.18 any interrupt moderation setting = 54% free (overall cpu) <-- htb+pie same speeds
it helps hfsc slightly, turning 97mbps cap into 111mbps but still crap nowhere close to 150mbps (default interrupts = <85mbps cap).
no interrupt moderation setting affects latency at all, its still doubled k3.18.
this is r34452
edit: wifi speeds severly capped due to extra ghost load, do any moderately sized wlan transfer locally and speeds will suck. while sirq load is through the roof.. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
for what its worth if it helps or not i found interrupt moderation setting on client nic is affecting cpu load for the first time ever. its affecting eth1 load on core 0, heavy reductions there, with a slight increase on core 1 eth0 wan load but overall load drops.
htb+fq_codel set for 150mbps/15mbps flat
wan interface is set to core 1 as its mandatory currently. rest of interrupts are default.
k4.x interrupt moderation off = 5% free (overall cpu)
k4.x interrupt moderation low = 12% free (overall cpu)
k4.x interrupt moderation med = 21% free (overall cpu)
k4.x interrupt moderation high/extreme = 30% free (overall cpu)
k4.x wifi = 21% free (overall cpu) <-- no interrupt mod control
k3.18 any interrupt moderation setting = 46% free (overall cpu)
k3.18 any interrupt moderation setting = 54% free (overall cpu) <-- htb+pie same speeds
it helps hfsc slightly, turning 97mbps cap into 111mbps but still crap nowhere close to 150mbps (default interrupts = <85mbps cap).
no interrupt moderation setting affects latency at all, its still doubled k3.18.
this is r34452
edit: wifi speeds severly capped due to extra ghost load, do any moderately sized wlan transfer locally and speeds will suck. while sirq load is through the roof..
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Wed Jan 17, 2018 20:09 Post subject:
maybe if cns3xxx is something used in r7800, but it looks like a ethernet driver for something else
edit: no just tried it, all k4.x issues remain, qos/latency/cpu load
stalonge wrote:
No news in a week ?
probably cause theres nothing to report, considering the same load issue is in lede/openwrt as well, and they supposedly have "good" qos compared to us, should mean this problem runs deep in this broken kernel _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
maybe if cns3xxx is something used in r7800, but it looks like a ethernet driver for something else
edit: no just tried it, all k4.x issues remain, qos/latency/cpu load
stalonge wrote:
No news in a week ?
probably cause theres nothing to report, considering the same load issue is in lede/openwrt as well, and they supposedly have "good" qos compared to us, should mean this problem runs deep in this broken kernel
Problem with this bug is, that 32bit arm has no nmi support, therefore the code that causes the load is hidden behind a standard kernel function that restores irqs.
Thus can't really debug it.