As far as I know, the NSS driver does not export or update the frequency via sysfs...but it is something that I have not checked on the driver itself, as either by Qualcomm suggestion or in my case, to ensure repeatability between tests, I force configuration and optimisation of diverse system parameters (and disabling NSS auto_scale is just one of them).
i made 20 speed test lan to wan
in the meantime, i installed transmission and downloaded a 5Gb torrent at around 20MB/s (MB, not Mbps)
in the meantime, i also did some wifi2wan speedtest (sadly, i have no fast wifi connection at home, i could just reach 283Mbps from an old samsung phone..)
it did not reboot
i need help to stress it more 
I hope i will have some sparetime this weekend, would really love to build an image for my Archer C2600. I have an heavily used Homenetwork with a wifi bridge (soon mesh) with 2 of those devices, meanwhile the main one see like 600gb per month going over wifi.
The partitioning for all ipq806x based Netgear devices changed between 17.01.x and 18.06.x, as their OEM firmware set up the kernel partition to small, if you jump between 18.06.x and 17.01.x based firmwares, you need to go the tftp route, in both directions, always.
To make switching between both branches easier, you could apply the partitioning changes to your 17.01.x based branch as well (making it compatible with 18.06/ 19.07/ master, but incompatible to OEM or normal 17.01; be aware that the network configuration may be different for NSS/ NPU based firmwares, so you can't retain your configuration over a sysupgrade either):
(both are needed).
2 Likes
Two crashes in about 20 minutes while using R7800 as AP with some moderate speed tests (80 to 180 Mbit/s LAN to WLAN).
With the same load: stable now since 1.75 hours. Keep you updated.
Setting the frequency seems to fix it rebooting at all, for me at least. using https://github.com/quarkysg/openwrt/commit/26e4a6dadda9c5ad49cd0dd4218d7f6e1bb361c6
is the extra speed just from sfe?
an hour is missing from cpu stats, put rrdtool output to usb
1 Like
for reference, after 3.5h, my 7800 rebooted
i was doing nothing relevant on network: i was looking at a movie via minidla, served from a usb disk.
so i started back the movie to see if for any strange reason this kind of usage could be linked to the reboot.
after 40 minutes, another reboot
now, i don't think minidlna could be the problem 
but the router survived gigabit burst for the speedtest and not a dlna movie?
now i understand this is something different than the UBI partition. sorry.
1 Like
@pattagghiu @slh is right. My GitHub repo only have the change to remove the Netgear partition, but still retain the 2MB kernel partition. 18.06 has the 4MB kernel partition. That means the flash partition sizes are different. So switching between 17.01 and 18.06/19.07/master will require flashing via tftp.
1 Like
@ratking we will need to force the NSS core to a fix frequency to have a stable R7800. The NSS core is different from SFE. The NSS drivers will try to scale the NSS core CPU frequency on demand and go down to it's minimal 110MHz frequency when it detects the router idling. It this scaling of frequency that is causing the router to become unstable and reboot randomly.
Workaround is to force it to it's max frequency of 800MHz. In any case, the NSS driver will force the NSS core frequency to max of 800MHz and stay there when the NSS crypto cores are used. So it should be OK to force it to 800MHz when the router startups.
1 Like
@BIGFAT do note that the NSS frequencies for ipq8064 will be slightly different from the ipq8065. The only change you need, from what I can gather, will be on the .dts files for the C2600. Do give it a go and help report back whether you can successfully get it going.
1 Like
Just keep in mind that the NSS cores are running at 733 MHz on ipq8064.
1 Like
Actually, the qca-nss-drv driver do expose the frequency of the NSS cpu core using the command before:
cat /proc/sys/dev/nss/clock/current_freq
It will then print it out into the console and it'll be logged by syslog. It'll be silent in the shell (telnet/ssh). Use logread to find out what's printed.
Another way to find out the clock frequencies are from the kernel clocks:
cat /sys/kernel/debug/clk/clk_summary
Below are the clocks used by the NSS cores:
nss_fabric_1_clk
nss_fabric_0_clk
ebi1_clk
afab_clk
nss_core_clk
ubi32_core2_src_clk
ubi32_core1_src_clk
nss_tcm_src
nss_tcm_clk
These are the clocks used by the crypto cores:
ce5_core_src
ce5_core_clk
ce5_h_clk_src
ce5_h_clk
ce5_a_clk_src
ce5_a_clk
2 Likes
i was referring to the extra network speed seen
could you just set 800mhz as the only freq seen in the dts or are scaling freqs needed
nss0: nss@40000000 {
compatible = "qcom,nss";
qcom,low_frequency = <110000000>;
qcom,mid_frequency = <600000000>;
qcom,max_frequency = <800000000>;
};
nss1: nss@40800000 {
compatible = "qcom,nss";
qcom,low_frequency = <110000000>;
qcom,mid_frequency = <600000000>;
qcom,max_frequency = <800000000>;
};
1 Like
We can't. The NSS drivers will need to load these from the DTS. If it can't find it, it'll fail to load.
1 Like
is this any help? just where it at least looks what clocks there is in the driver, i just have it echo'd in case of a reboot
1 Like
The nss_hal/ipq806x/nss_hal_pvt.c codes are used during device probe to setup the NSS cores and it's associated clocks.
The actual codes to scale the NSS core frequencies during runtime are located in:
nss_init.c
nss_freq.c
I tried to figure out the root cause, but so far hasn't been successful. The scaling works mostly, but there seem to be a 'bug' somewhere where the set of clocks may not be set correctly in tandem and thus likely crashing the NSS firmware, causing a spontaneous reboot. In any case, since forcing the clock to a fix rate worked around this issue, I moved on to enabling more features before returning to try and solve this 'bug'.
1 Like
Hi quarky,
You are right about the current_freq and I remember that I spotted that "silent" output when I first tested it (weeks ago).
The thing is that that "silent" output was also happening when using the serial console for me and only when running dmesg, I could see the entry "Frequency Set to 110000000" (which by the way, also happens for the inst_per_sec).
I have not checked on other old platforms using Kernel 3.4.xxx and IPQ8064, but I have the idea that it was working before on those kernel revisions...will check.
@pattagghiu Sorry for providing wrong information.
From line 886+ looks noteworthy...
@anon50098793 thanks! Will study the code. Prelim glance seems to suggests it's for WiFi offload, which my firmware changes still does not support. But increasing the NSS to host buffers may help if it's due to buffer overwrite when NSS is sending data over to the host.
Scenario 2
Still stable after 2 day. Max. thruput I could muster with my clients was 220Mbit/s with an 433Mbit/s WLAN connection.