Anyone know if this will help against bufferbloat?
I get a C on the dslreports bufferbloat test on a 100/100mbit connection. I also noticed that tcp segmentation offload seems to be off by default now.
I would use SQM cake for dealing with Bufferbloat
It is using 100% of a single core on my 50/10M connection, so I am not sure how that will help with 100/100M connection...
1 core 100% usage?. That is aggressive.
I have a wrt1900acs/17.01 with SQM piece of cake for a 50/50mbit and the router never "sweats". Also with the R7800/17.01 no problems at all. I have more or less 10 devices connected at peak time streaming, browsing, gaming and no big deal!.
BTW in both routers tcp-segmentation-offload is on. So i get that in master tcp-segmentation-offload is off by default?
It is what it is.
I would want to know that too, but in R7800 it is all off by default.
Well i can say that it is on in my r7800 build.
root@OpenWrt:~# ethtool -k br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
But i'm using @quarky build
the build includes qcom-nss-gmac and qcom-nss-drv modules instead of the standard stmmac
Is it running reliably?
Yep i find it very stable, and the ping spikes are lower. But i guess your network is more "heavy duty" that mine so it is advisable that you test it more thoroughly.
Still we need to include the qcom-nss-ecm (enhanced connection manager) that will unlock the nss cores full potential, for example qdisk acceleration.
I've just needed to reboot it once in 26d due to a wifi crash. The rest of the time .. smooth operation.
sorry bug as far as i can see they didn't manage to make the nss core work... am i wrong?
Unfortunately, you’re correct. Still trying to figure out how the ARM CPU communicate with the NSS cores. Missing some driver, which I’m still trying to figure out.
Although the NSS driver is loaded, it looks to me that the apps fabric bus/clock is not initialised. So the NSS core CPU is not running the NSS firmware code. Kind of stuck at the moment.
Take a look at the bootloader modifications by QCA, which might provide some insight, as NSS firmware is apparently already loaded from there (and cmdline).
yes... in the uboot source there is some nss code... problem is the dts file i think...
The NSS firmware is loaded by the qca-nss-drv driver. The firmware is > 400KB which is not possible to have been loaded by U-Boot. Besides the factory firmware is using the same U-Boot.
As for DTS, I have (I think) the nescessary info from CodeAurora. But the CodeAurora linux kernel (v4.4) has been heavily modified from the standard Linux source so that is a problem for me as well.
Here's from hnyman's master build:
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off [requested on]
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: off
But it also depends on what iface you are looking at, so I'm a bit confused why it shows different settings for them.
the interface should be br-lan
There is now a new patch for bumping the kernel to 4.14:
http://lists.infradead.org/pipermail/lede-dev/2018-April/011895.html
and the issues I've found on the nbg6817 (PCIe fails to initialize, therefore no wlan, kernel size too large for the r7800 - not an issue for the nbg6817):
http://lists.infradead.org/pipermail/lede-dev/2018-April/011900.html
1 Like
A very initial test on the nbg6817 (https://github.com/pkgadd/openwrt/tree/ath10k-firmware-features-1) looks positive, I'll file that branch as pull request after a few days of testing.
http://lists.infradead.org/pipermail/ath10k/2018-April/011269.html
"just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
crashes in vht160 operation mode immediatly after first station associates
last known working stable fw so far is 10.4-3.4-00104. the whole
10.4.3.5.3 series seem to be seriously broken or the api has been
changed in a way
which is unsupported by ath10k (which i think is the cause of the problem)
it would be good to know what has been changed." 
can confirm this...