In the next major stable release, 24.xx somewhere later this year.
DSA change is so big that it will not be backported to 23.05
1 Like
@hnyman is the cpu scaling issue still present? I run the router at performance speeds now. I used to run it with ondemand before but I did experience crashes back then (build was from around 2022).
I've been testing kernels 5.15 and 6.1 on router Xiaomi R3D (ipq8064) for 2 months now.
Ondemand Governor consistently causes the kernel to crash in different places. I believe that how the memory mapping breaks is because dmesg shows that the memory contains incredible values.
When switching to a performance governor, all these troubles disappeared and no longer occur!
And it seems that there are no such bugs on the 5.10 kernel! (but it is not exactly)
I wrote to @Ansuel about this a long time ago, but he did not answer.
1 Like
I am going tow-2-tow (and losing) with why my 5ghz wifi on my r7800 23.5.2 is now all kinds of unstable. iv read that 5 ghz is unstable for lots of folks but its like its went from being just fine to now its randomly disappearing and dropping all clients until I reboot the r7800. even then its just a matter of hours or so before it comes back. iv tried both ct and non-ct drivers and syslog doesnt capture anything at the time is drops out. i live in the US in a 3 story apartment with the r7800 AP on the second floor. maybe interference with another one of the 20+ SSIDs that show up nearby. iv tried various random (unused channels per wifi analyzers) but doesnt seem to matter what channel. some won't even come up. Ohh the joys of opensource/diy firmwares. 
Have you tried setting the wifi channel to 'auto'? If you specify a given channel, if there's interference which shuts down that channel the radio stays off.
You can specify a channel range to use, but only via the command line.
Yes. Its at auto now (landed on ch36). but if I connect my galaxy s23+ to the 5ghz wifi from literally 2 ft away and ping the ip of the r7800 from my phone it avreges maybe 10-20ms ping may drop down as low as 3 or 4ms but then will timeout (and may or may not disconnect my phone from the ap) for maybe 5 seconds or so then come back to life. when it times out nothing shows in logs and it seems to be only 5gz radio itsself that bugs out. the r7800 never really seems to skip a beat.
I used wifi analyzer to see a channel thats free of other visible aps in the area but when I do manualy set that channel it disables itsself. I was only able to get a few channels manually set and work (until it burps again).
Thanks!
I want to try to connect an eSATA disk device to the router and try how it will work.
I've already tried USB3 and now want to try eSATA. I know that I should install kmod-ata drivers.
I've read this post but I'm not sure what kmod driver/s are suitable for R7800.
I've found this page https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL
and downloaded latest original Netgear firmware Open Source Code GPL
https://www.downloads.netgear.com/files/GPL/R7800-V1.0.2.92_gpl_src.zip
but I cannot seem to find the proper kmod-ata drivers NG uses for R7800 in stock firmware.
Does anyone know what driver works with R7800 or I'll have to add blindly and try.
Thanks in advance.
Has anyone here tried to use eSATA device?
While IPQ8065 does have SATA3 capability, this is likely not connected in R7800 as its ESATA port shows up as drive USB0 so is presumably attached via USB 3.0.
Therefore ESATA port should be no faster than USB 3.0 or have any less CPU utilization. A pity as NAS devices using the same CPU but native SATA can saturate gigabit with a SATA disk, while USB just runs out of CPU.
1 Like
So in this case only USB3 drivers are needed even for eSATA, right.
Xiaomi R3D (ipq8064, USB3.0, SATA 3.1), OpenWRT snapshot 6.1.77, Seagate 1TB 3.5"
root@OpenWrt:# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1476 MB in 2.00 seconds = 738.74 MB/sec
Timing buffered disk reads: 510 MB in 3.01 seconds = 169.43 MB/sec
fio: Test write throughput by performing sequential writes with multiple parallel streams
> rm -rf /media/disk/test1
> mkdir -p /media/disk/test1
> fio \
--name=write_throughput \
--directory=/media/disk/test1 \
--numjobs=4 \
--size=100M \
--time_based \
--runtime=60s \
--ramp_time=2s \
--ioengine=libaio \
--direct=0 \
--verify=0 \
--bs=1M \
--iodepth=64 \
--rw=write \
--group_reporting=1
write_throughput: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=64
...
fio-3.34
Starting 4 threads
write_throughput: Laying out IO file (1 file / 100MiB)
write_throughput: Laying out IO file (1 file / 100MiB)
write_throughput: Laying out IO file (1 file / 100MiB)
write_throughput: Laying out IO file (1 file / 100MiB)
Jobs: 1 (f=1): [_(2),W(1),_(1)][58.0%][w=44.1MiB/s][w=44 IOPS][eta 01m:00s]
write_throughput: (groupid=0, jobs=4): err= 0: pid=11083: Fri Feb 23 10:29:51 2024
write: IOPS=1, BW=2399KiB/s (2457kB/s)(183MiB/78111msec); 0 zone resets
slat (msec): min=11, max=4224, avg=1825.77, stdev=613.33
clat (usec): min=45, max=82237k, avg=64740745.62, stdev=17990659.71
lat (msec): min=4294, max=82241, avg=66451.18, stdev=15263.98
clat percentiles (usec):
| 1.00th=[ 52], 5.00th=[17112761], 10.00th=[17112761],
| 20.00th=[17112761], 30.00th=[17112761], 40.00th=[17112761],
| 50.00th=[17112761], 60.00th=[17112761], 70.00th=[17112761],
| 80.00th=[17112761], 90.00th=[17112761], 95.00th=[17112761],
| 99.00th=[17112761], 99.50th=[17112761], 99.90th=[17112761],
| 99.95th=[17112761], 99.99th=[17112761]
lat (usec) : 50=1.15%, 100=3.45%
lat (msec) : >=2000=205.75%
cpu : usr=0.11%, sys=0.14%, ctx=751, majf=4, minf=256
IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=32.2%, 32=67.8%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=100.0%, >=64=0.0%
issued rwts: total=0,87,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=2399KiB/s (2457kB/s), 2399KiB/s-2399KiB/s (2457kB/s-2457kB/s), io=183MiB (192MB), run=78111-78111msec
fio: Test read IOPS by performing random reads, using an I/O block size of 4 KB and an I/O depth of at least 64
> rm -rf /media/disk/test1
> mkdir -p /media/disk/test1
> fio \
--name=read_iops \
--directory=/media/disk/test1 \
--size=100M \
--time_based \
--runtime=60s \
--ramp_time=2s \
--ioengine=libaio \
--direct=0 \
--verify=0 \
--bs=4K \
--iodepth=64 \
--rw=randread \
--group_reporting=1
read_iops: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.34
Starting 1 thread
read_iops: Laying out IO file (1 file / 100MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=3147KiB/s][r=786 IOPS][eta 00m:00s]
read_iops: (groupid=0, jobs=1): err= 0: pid=11174: Fri Feb 23 10:33:07 2024
read: IOPS=785, BW=3146KiB/s (3221kB/s)(184MiB/60002msec)
slat (usec): min=802, max=21161, avg=1235.39, stdev=213.59
clat (usec): min=39, max=157113, avg=80178.44, stdev=3705.15
lat (usec): min=1388, max=157918, avg=81413.84, stdev=3709.84
clat percentiles (msec):
| 1.00th=[ 79], 5.00th=[ 80], 10.00th=[ 80], 20.00th=[ 80],
| 30.00th=[ 80], 40.00th=[ 80], 50.00th=[ 80], 60.00th=[ 81],
| 70.00th=[ 81], 80.00th=[ 81], 90.00th=[ 83], 95.00th=[ 84],
| 99.00th=[ 90], 99.50th=[ 93], 99.90th=[ 150], 99.95th=[ 155],
| 99.99th=[ 157]
bw ( KiB/s): min= 2682, max= 3248, per=99.89%, avg=3142.83, stdev=50.47, samples=119
iops : min= 670, max= 812, avg=785.52, stdev=12.64, samples=119
lat (usec) : 50=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.02%, 50=0.05%
lat (msec) : 100=99.92%, 250=0.13%
cpu : usr=1.19%, sys=98.11%, ctx=737, majf=0, minf=0
IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=47121,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=3146KiB/s (3221kB/s), 3146KiB/s-3146KiB/s (3221kB/s-3221kB/s), io=184MiB (193MB), run=60002-60002msec
1 Like
hi,
i been a user of your build for a long time now, using the last stable version [OpenWrt 23.05-SNAPSHOT (r23751-eda5930d43)], i m having lots of disconnect situation form my 5Ghz wifi connection (2.4Ghz is disabled). I have tried a bunched of things without any success.
here are the logs i see
daemon.notice hostapd: phy0-ap0: AP-STA-DISCONNECTED
kern.warn kernel: [ 2548.115282] ath10k_pci 0000:01:00.0: Invalid VHT mcs 15 peer stats
let me know what other logs i could pull may help .
thx
Sorry, I don't use my R7800 that much any more, and during those periods when I use it, I haven't noticed any problems myself.
But in general terms, there is nothing specially changed for wifi in my build.
So, the possible problems should manifest themselves also for other ath10k-ct wifi driver users.
2 Likes
Thank you, by curisosity and if it's not too intrusive ,which one are you using for openwrt
- Mainly MT6000 and somewhat DL-WRX36 as the main router (R7800 occasionally when testing new build), and
- E8450/RT3200 as the dumb AP.
R7800 is still good and stable, but only wifi5 (802.11ac), while newer routers are wifi6 (802.11ax).
And R7800 (without NSS) can't keep up with 600/200 Mbit wan connection
3 Likes
That MT6000 looks interesting, might get one. thx
R7800 does 1gbit wired and in my tests it easily saturates 500/500 on wireless even when using 2x2 iphone 12 pro. But ofc without sqm/ traffic shaping.
MT6000 cant do sqm above (one way) 400-450, and it’s not that much faster than R7800 on wifi while having less coverage.
I’m not making a big argument, it’s just that for most people the improvements are marginal at best. Think i’ll stick with my R7800 till wifi7 becomes commonplace.
Dear hnyman,
How are you doing ? - well I hope. I am getting two MT6000's on Friday - and I already have two DL-WRX36's - but I am still a bit leery about flashing the DL-WRX36 as the process seems a bit fraught with danger.
anyway, I like being able to go back to stock firmware on my hardware - and for the life of me - I am unable to fully make sense of how to go back to stock on the DL-WRX36. The instructions on the thread / wiki are a bit murky - at least IMHO.
Regarding Kernel 6.6 on R7800 - I am interested in what you think / have to say.
I attempted to build ipq806x 6.6 R7800 but I got no joy in the end - anyway - hopefully I will hear from you soon. Oh by the way, will you be building for the MT-6000 - just asking is all
Peace and God Bless Always
ipq806x: 6.6: add kernel 6.6 as a testing kernel version #14934
EDIT : Further Information Below - I got the same results using 14934.patch
1 Like
I will not publish a proper community build like I have done for R7800, but I am still uploading my builds for MT6000 and DL-WRX36 into Dropbox.
Forum search would have revealed these posts and links to you:
Ps.
The DL-WRX36 flashing instructions are pretty clear, but the installation is really complicated and consists of several steps. (The option 1A, using a modified OEM backuåp, is the a bit simpler choice)
2 Likes
What firmware is your build using. I'm not seeing this on mine with standard firmware:
dmesg | grep firmware
[ 32.839052] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.9.0.2-00157 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 6cdc6ff9
[ 39.565968] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00157 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 6cdc6ff9
Could be an issue in ct firmware.
My builds are using the OpenWrt default, meaning -ct firmware and driver.