Next router? ath10k or mwlwifi based? something else?

I haven't got it yet. DHL still has it (likely the DHL postal service, so it will take a few days) :frowning:
I will report my experiences after I have got it and flashed it with LEDE.

@hnyman - I'm really interested in hearing how you make out with the R7800. I've been thinking of one since the Summer. They are $199US at Amazon this week and I think I may grab one to replace a Ubiquiti RSPRO with Ath5K and Ath9K cards.

I also have a 2nd RSPRO used as a bridge plus extended Wifi coverage. I'll probably keep that or replace it with something less expensive with decent thru-put if such a thing exists.

I'm pretty sad no one is releasing newer mini-pci cards :confused:

They are, but the reference design is non standard form factor which is an issue in many cases.

I cannot find the R7800 within the "Table of Hardware", are you sure it is supported by OpenWRT/LEDE?

[quote="Ted, post:25, topic:80, full:true"]
I cannot find the R7800 within the "Table of Hardware", are you sure it is supported by OpenWRT/LEDE?
[/quote]I sincerely hope so :wink:

The commits are there https://git.lede-project.org/?p=source.git&a=search&h=HEAD&st=commit&s=R7800 and the LEDE buildbot nicely churns a build for R7800 (in https://downloads.lede-project.org/snapshots/targets/ipq806x/generic/ ), so I guess that the support is there, at least on the LEDE side.

I have actually already compiled a LEDE firmware for it. (but have naturally not installed it, yet...)

It is so new (support created after the Openwrt/LEDE split) that there is no entry in Openwrt ToH (that has been the base for LEDE ToH).

EDIT: Actually, the absense of the device from ToH was likely the main reason why it did not surface on my radar when I looked for the devices before starting this thread.

Looking forward for your test result, especially for the 802.11ac wireless stability and performance.

I got the R7800 device today. I used the native OEM GUI to flash LEDE and that went ok without any trouble. I haven't really tested the device yet as I have just used it for an hour, but I at the first glance things work ok. I get roughly 75/9.5 Mb/s throughput from Ookla speedtest with 3ms latency with wifi and SQM simple at 85/10 limits. I have not yet tested with flent or any other more sophisticated tool.

Some observations on R7800 and LEDE support:

  • eth0 and eth1 are apparently swapped, so I have to tinker with SQM etc. default configs a bit.
  • with default LED settings the USB LED does not turn on when an auto-mounting memory stick is inserted. a hotplug script, default config or device tree modification is needed? (EDIT: that is apparently due to wrong/different usb port numbering used in the latest commit for this device. changing ports 2-1 and 4-1 to 1-1 and 3-1 (and converting them at the same time from usbdev to usbport) fixed things.
  • CPU frequency scaling works. It seems to scale from 384 MHz on idle to 1700 MHz under load. I wrote two days ago an addition to Luci statistics that shows the CPU Frequency graph (and turned that collectd module on for ipq806x in my build)
  • wifi LEDs are attached to wifi_on/off and WPS LEDs in device tree since a commit a few days ago. I wonder about that.

So, there is room for some further development, but all in all the device seems to work ok with LEDE.

Good to hear, you might want to have a look at the netdata package if you can live without luci integration and since you're using SQM you might want to raise the kernel HZ frequency to 1000 if it isn't the default setting.

Just a brief comment that I did a new build for R7800 and sysupgraded via GUI. No problems.

I got the USB LEDs fixed at the same time. I will send a PR to fix the USB port numbering in the port detection script.

Great!
How about the 802.11ac wireless stability and performance?

Could you @diizzy elaborate more on that? I think that ipq806x has still the old default of 100 Hz as the kernel frequency. Do you have experience in raising that value to either 250 or 1000 on this platform?

I have noticed some substantial gap between the targeted download speed in SQM and the actual download speed with R7800 (especially with simple/fq_codel, something like 90Mbit vs. 77 Mbit, while cake seems to provide better throughput). I did not see similar effects with my old WNDR3800, so I wonder if this is something special for ipq806x and if raising the kernel Hz would really help. Or alternatively, if something in the quite recent kernel bumps have caused performance regressions in general. I will probably need to test more thoroughly with "flent".

And I might test also with the increased kernel Hz frequency, as some of the other platforms seem have 250 as the default already now.

To expand the previous:
I have stumbled upon strange behaviour of R7800 with SQM using simple/fq_codel:

  • There is a significant speed gap between the set download speed limit and the realised download speed, as measured by flent.
  • With cake the same speed limit produces significantly higher download speed.
  • My old WNDR3800 (ar71xx) produces the same speed with cake and simple as R7800 with only cake.
  • Increasing the download speed limit by 10 Mb increases the actual download speed by maybe 7 Mbit/s, so the router is not hitting any real CPU or I/O performance limit.

It is almost like the simple/fq_codel would produce in ipq806x a realised download speed of some 75% of the set limit. With the old trustry ar71xx/WNDR3800 the speed gets higher, to near the CPU hardware limits.

This almost looks like there is some kind of calculation bug in the fq_codel code when compiled for IPQ806x (code base is arm_cortex-a15_neon-vfpv4 )

Any clues to what could cause this? How to debug?

  • Can router's automatic CPU frequency scaling (between 384-1700 MHz according to load) cause trouble for codel? But not for cake?

I don't use any qos, but I saw dd-wrt has the same issue, it uses kernel 3.18. You can try to set performance governor so it maxes CPU frequency without scaling and check if it has any affect

Yeah, so it seems. Example of the discussion there: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1050453#1050453

Looks like there is still something in the dts file that throws some timings slightly off, hitting fq_codel most.

I suspect this issue is related with this: when you benchmark OpenSSL speed with "openssl speed sha256", you watch how it tests different packet sizes with 3 secs interval, but in fact it's sometimes not 3 secs but 2.97, 2.99, 2.95 secs and so on. I suspect that opensource is missing some driver that syncs clocks between subsystems in a soc

I opened a separate thread for R7800-specific discussion:


I moved the latest messages there and will leave this thread for general discussion about new devices.

I hope that discussion here continues and interesting options get introduced.

setting HZ=1000 means that you have a much finer granularity of schedulers and packet handling. I'm pretty sure that Cerowrt sets this by default and I know it's the recommended setting in FreeBSD (and default nowdays).

Thanks to dlizzy (in the other thread) I've decided to get NBG6817 because I found it for a very interesting price over here. 169$. it is way cheaper than r7800 here and since they have the same hardware that was an easy choice :slight_smile:

I just didn't quite understand the flashing procedure for NBG6817.
it say:
For installation copy xx-mmcblk0p4-kernel.bin and xx-mmcblk0p5-rootfs-full.bin
to device. Then run:
cat xx-mmcblk0p4-kernel.bin > /dev/mmc0blk0p4
cat xx-mmcblk0p5-rootfs-full.bin > /dev/mmc0blk0p5
reboot -f

do i normally SSH to it or what do I miss here? and how to revert it back to factory if I will need it?
Thank you in advance.