It seems that there is not a lot of support for the R7800 for either of the big open-source firmware communities. The DD-WRT build is still stuck on the 3.18 kernel and on LEDE the master builds have horrendously slow WiFi performance but nobody seems to be willing/able to address it.
I really regret getting this device.
Why not use the stable builds... Master is more experimental after all. No issues on stable for me in terms of WiFi. There is pretty good support for this unit, compared to a lot of other devices, I don’t know what you really expect. I mean do you really expect it to beat stock WiFi performance using proprietary drivers? LEDE 17.01.2 is pretty close... It’s popular at DD-WRT as well and they use and older kernel for a range of devices not just the R7800...
On stock it’s the best performing 5Ghz unit in terms of range and speed, on the consumer market.
The stable version is still on 4.4 kernel,so I go with master.
But I will try to go back to stable version later,see if it works
Hi,
Currently I run this build
LEDE Reboot SNAPSHOT r4694-e7373e489d / LuCI Master (git-17.223.47793-8bc1971)
and it worked fine.
But after 20 days of uptime router rebooted. I didn't find something wrong in the logs after it.
What is most stable Lede build can I use? Is it official Lede 17.01 or smth from hnyman's list?
What's so special about 4.9? 4.4 has a bunch of stuff backported from newer kernels. It's not stock.
Sorry to quote such an old post, but I do experience the same problem...
I have 2 routers, Linksys EA8500 and Phicomm K3. EA8500 has an IPQ8064 which is much like R7800, and K3 has BCM4709. They all have the same problem as dissent1 described in that post (reproducible by all WiFi and wired connections). Data streams going out of the router are capped at 300Mbps (<100Mbps for WiFi) but streams flowing into the router are just fine.
EA8500 is running at revision r49xx which was built several days ago without any additional patches missing from master, and K3 is running at an old build made in May. Source code for K3 is uploaded here, I have done basic porting only so it was also a "clean" build.
Maybe we can make a wild guess that something went wrong in common logic in kernel, since different platforms and different PHYs are affected...
Actually it was my bad with that iperf test capped at 10-15 mbits - I’ve backported some patches from upstream kernel and missed some other dependencies.
Anyway there’s really smth strange going on because mt7621 (2x880mhz mips) device outperforms ipq8064 and on par with ipq8065 with NAT/QoS traffic.
If someone wants to test performance difference there is k4.13 stmmac driver in my tree that you can pull.
https://github.com/dissent1/r7800/commit/47751d79795c1d1c67232ef0cd7f24b4a9f3f4c1
I've recently switched to an mvebu router and found there to be a massive difference. It's more responsive, the Ethernet speeds are more consistent,, lower latency too. The wifi is not as good but I think it's worth it.
dissent1's right, there's something weird going on. The R7800 should not be performing like this.
I second this.
I own TP-Link Archer C2600 with IPQ8064 and it has troubles keeping up with 250/20 Mb/s connection with SQM layer_cake. I've seen people in this thread pointing out a low performance of units based on IPQ806x compered to the Linksys devices. I even asked about it here and got no response.
Apparently Netgear R7800 can't handle 300 Mb connection with LEDE. It's laughable really. I've also seen reports that my C2600 could previously handle 800 Mb/s connection of NAT alone. Now it can't even do 500 Mb/s. That was from a guy that actually tested this router some time ago and repeated those test recently. He said that "they changed something with the switch (inside LEDE) and now there is a problem with 500 Mb/s connection".
It’s not the switch driver, I use different switch driver. And iperf to the R7800 shows gigabit speed, probably meaning that eth driver also acts more or less ok. It’s smth different, that relates to forwarding. Or maybe eth driver eats up a lot of cpu so not much left for natting/forwarding.
Try pulling stmmac update linked above.
Tried the stmmac patch but make no difference.
It can handle close to a gigabit across the LAN/WAN port in NAT mode, I (and others) have tested that extensively.
Edit: that's with the FASTPATH patch applied btw, didn't test without.
With Fast Path even WR1043ND v4 with 750 Mhz Single Core MIPS CPU can get near Gigabit speeds.
Another platform using stmmac had the same problem (low upload speed) and users found a workaround here. I could not test this as I don't have access to my router now...
I guess it's not our case
Wonder if it may help us somehow
http://svn.dd-wrt.com/changeset/33429/src/linux/universal/linux-4.9/drivers/nvmem/core.c
If it affects nvmem reads, could be that nvmem returns incorrect value
Has anyone experimented with the hwrng in this device? I have an implementation I am working on that needs a significant amount of sources of entropy and what I am currently finding isn't enough for my scenarios. Well, it's not enough to make me comfortable, that is. Thank you.
-Shaun
There is discussion about that in this same thread...
As far as I know, the hwrng in R7800 is still a pseudo-rng, but produces good amount of entropy that can be piped into kernel pool via the rng-tools package.
Hello!
It seems that something changed in 17.1.3 vs 17.1.2 in openssl results of dsa verify:
I tested both. Please see last number.
17.1.2 results:
| r3435 | ARMv7 Processor rev 0 (v7l) | 6.00 | ARMv7 Processor rev 0 (v7l) | 56.15 | Qualcomm (Flattened Device Tree) | 1.0.2k | 140149300 | 181368490 | 131009190 | 67100080 | 24305440 | 8929690 | 65237670 | 56827900 | 51760130 | 131.7 | 5914.3 610.9 | 593.7 |
17.1.3 results:
| r3533 | ARMv7 Processor rev 0 (v7l) | 12.50 | ARMv7 Processor rev 0 (v7l) | 56.15 | Qualcomm (Flattened Device Tree) | 1.0.2k | 140083880 | 180450300 | 130343250 | 67257900 | 24805460 | 8888870 | 63706450 | 55427170 | 50563070 | 132.8 | 6013.6 607.1 | 1.3 |
Do you know why?