Build for Netgear R7800

Your process is fine, but the old database (with 32bit timestamps) is incompatible with the new 64bit time.

I converted my own historical database to 64bit by exporting the data with rrdtool to XML in the old 32bit firmware...
... and then after copying the XML files to the new firmware, use rrdtool in the new firmware to import it from XML to 64bit rrd.

Google for "rrd convert 32bit to 64bit". I found a handy python script that converted all dozens of individual files at one go.

https://www.google.com/search?q=rrdtool+convert+32bit+64bit

But the process requires to use the old firmware for export, and then a new one for import.

1 Like

Thanks, got it. I'll try and let's see how it goes.

Moved to the newest build (from 19 to 21) and speeds have dropped from 4-500 megabits/s to 2-250.

Anyone else experience similar?

Can we use sysupgrade to downgrade back to 19?

For those who are building by themselves based on @hnyman 's scripts DSA test build (at least that one) since a few days has problems with Ethernet driver. Here is a proper list of interfaces while running hnyman's DSA build from September 29th:

Summary
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f3 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
4: lan4@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff permaddr 8c:3b:ad:10:54:f3
5: lan3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
6: lan2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff permaddr 8c:3b:ad:10:54:f3
7: lan1@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
8: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f3 brd ff:ff:ff:ff:ff:ff
9: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
10: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
11: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
20: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
21: br-lan.1@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
22: br-lan.3@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
23: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 8c:3b:ad:10:54:f4 brd ff:ff:ff:ff:ff:ff

And here is the same list with newer build:

Summary
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1502 qdisc noop state DOWN qlen 1000
    link/ether 8c:3b:ad:10:54:f3 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1502 qdisc noop state DOWN qlen 1000
    link/ether 8c:3b:ad:10:54:f2 brd ff:ff:ff:ff:ff:ff
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 8c:3b:ad:10:54:f4 brd ff:ff:ff:ff:ff:ff
10: br-lan.1@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 8c:3b:ad:10:54:f4 brd ff:ff:ff:ff:ff:ff
11: br-lan.3@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 8c:3b:ad:10:54:f4 brd ff:ff:ff:ff:ff:ff
17: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 8c:3b:ad:10:54:f4 brd ff:ff:ff:ff:ff:ff

Brief update on stats patching.

, all good and historical stats retained. Thanks @hnyman

You can downgrade to 19 but some settings may be lost. B/G compatibility mode may get reenabled in WiFi for instance.

You can also try upgrading to another 21 or master branch which is for NSS hardware acceleration, you're unlikely to lose settings there.

In particular, try R7800-20210912-MasterNSS-ath10k build while it is still available. Make sure to NOT use SQM in the UI (it does not support it), and make sure to DISABLE SOFTWARE ACCELERATION in that build (that's what creator says).

I'm running that particular build right now and it seems more stable and faster than previous ones, though admittedly it's not been a whole week.

master-r17681-297cb8c147-20211005

ath10k-ct seems to have finally fixed DFS with 80/160 MHz wide bands.
There is a PR for OpenWrt that is still uncommitted, but I have imported it into this build.

2 Likes

How is the stability with 5.10 ? Does anyone notice any regression ?

No regression as such, I've been on v5.10 (nbg6817, g10) for the last ~half year - but uptimes rarely exceed two weeks (sometimes it crashes earlier), but that already affected v4.19 and v5.4.

1 Like

I have not noticed anything strange with 5.10 in my R7800.

1 Like

i honestly wonder if the problem is related to lack of nss firmware...
example i'm testing a device from ages with a special experimental image of 5.10 + nss accelleration and a special scaling driver that scale a clk using the same way qcom do... this clk is also related to the eth clk (it's shared) wonder if it's caused by that.... example now i'm at 5d of uptime but i remember having 25 days of uptime with this image... also it was overclocked just to add stuff to it and it was stable for some reason... can't really understand.

The weird part is that there is no real reason for this either. I've kept logread over ssh running for a while (rather than real netconsole), but the router just silently rebooted without any error message making it over logread/ ssh. The timing is also variable, most of the time around 13-15 days, but sometimes also after 1-2 days of uptime, I can't really point my fingers anywhere specific.

Case in point, I've let the 'new' (second hand) running (successfully/ continuously) for a month (behind my nbg6817, double-NAT, mostly serving wireless only - so not a whole lot to do) before (sys)upgrading it again, yesterday it rebooted after around 15 hours uptime - so far it's keeping up (26h).

Not sure if there’re massive differences between 5.4 and 5.10, but my R7800 running 21.02 + NSS + back ported L2 freq scaling driver from master has been up more than 53 days now.

From what I can see, the difference between builds with and without NSS enabled are the initialization of additional clocks and the NSS cores. Maybe without those initialized it may be causing the Krait cores to stall and watchdog timer taking over to reboot?

actually i notice we are completely missing the watchdog node entry and the extra clk... wonder if that's the cause...

2 Likes

Did the regular ath10k driver (that you supply separately) have this issue?

Not according to the code, but I've never tested it in practice.

Please note

It is possible that we revert back to the 32bit time in RRD in 32bit targets.

1 Like

Ok noted.

While not the end of the world if losing historical stats, assuming process works backward as well, meaning xml dump in 64bit and restore in 32bit system?

Sure, it should work.
Personally I restored my old 32bit database from Sept 24, and lost the data of the two recent weeks. Easiest and good enough for me.

1 Like

Good, main point is learning something new (like converting successfully rrd database).