No but you need to reset switch config and add new interface to br-lan
If you have WiFi you can do this manually
Yeah, another crude hack:
Nope. Basically the switch is currently configured by swconfig. DSA makes each switched port its own interface. So instead of just eth0, it becomes (eth0 eth1 eth2 eth3 and eth4). Somewhat confusingly, it's actually named lan1 lan2 lan3 lan4 and wan with eth0 as the CPU port.
Actually it's eth0 and eth1 as the R7800 has 2 CPU ports.
Hopefully you got a sense of how complex it can get.
I actually think this argument that compatibility should be kept between different versions of OpenWrt is totally bogus. Writing a script like this is not only error prone, but compatibility is already something not satisfied. Going from CC to LEDE breaks dnsmasq.
Or just reset to default settings. board.d should configure things properly.
Or goes in failsafe mount root and edit from there
I came up with this
Cam someone test? Will send patch if successful.
That is the wrong place to make the change: R7800 is using QCA8337. See my post for the line that you can change: Possible cause of R7800 latency issues - #154 by fantom-x
This is the idea:
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 96267d4..7df912a 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -1506,7 +1506,7 @@ const struct ar8xxx_chip ar8327_chip = {
};
const struct ar8xxx_chip ar8337_chip = {
- .caps = AR8XXX_CAP_GIGE | AR8XXX_CAP_MIB_COUNTERS,
+ .caps = AR8XXX_CAP_GIGE /*| AR8XXX_CAP_MIB_COUNTERS*/,
.config_at_probe = true,
.mii_lo_first = true,
It's using the 8327 driver...weird.
Guess gca8k didn't exist yet.
Not, it is not. See the line ar8216.c:1841...
case AR8XXX_VER_AR8337:
priv->chip = &ar8337_chip;
break;
Yes, it will be confusing. Can the right driver be loaded based on the contents of the config file? Or can there be two firmwares (old & new drivers) for the transition period?
It depends on the DTS file. See the Turris Omnia pull request.
It enables DSA while disabling it for the current units with support for swconfig.
Basically you can have both drivers. but which gets used depends on the dts file.
Swconfig should support DSA... That way don't need to have different configuration...
Erm DSA is a kernel thing. The main issue is having a script that converts from a single interface to multiple interfaces.
It's so strange that we don't have one as DSA is supported for mvebu too...
The DSA framework is relatively new (you really want at least kernel 4.14 for DSA drivers) and -as mentioned before- upgrade support for existing devices is a concern. For devices (and uplinks) with very fast routing performance (this mostly affects mt76xx and mvebu) there is also still a small drawback, right now DSA only supports a single CPU port (ipq8065 offers two in hardware, one for WAN, one for LAN). While it is expected that the DSA will also gain support for multiple CPU ports in the not too distant future, the current restriction to one CPU port does limit maximum (especially full-duplex) throughput for now.
I guess you can expect common/ contemporary devices to be ported to DSA in the future (for the simple reason that only DSA is accepted mainline), but there isn't a huge urgency for most existing ones - combined with a lot of work (testing all affected devices one by one) and some regression potential. It's just easier to require new device submissions to support DSA, than porting the bulk of existing ones - but the port maintainers would probably appreciate any help with this; especially for devices (like qca8k) which do have upstream support for DSA.
1 Like
The 1 CPU port thing is a bit misleading. Usually DSA drivers are faster as they sometimes offer some hardware acceleration. They also sit in kernel space whereas swconfig (I believe) is in user space.
So the slowdown isn't 2x in most cases.
Then there are devices with only 1 CPU port (my Archer C7v4 for example) where this is not an issue. Not that there's DSA for it yet... Although it would be a good idea to use qca8k for it when it gets ported to ath79.
1 Like
That is all good, but could be getting off topic. Either way, DSA is a long term solution, but the problem exists now. As far as I am concerned, the latency problem is mostly solved: I am running a custom firmware that is very fast and also eliminates most latency spikes over wifi. The latency over wired is even better. It does take a number of patches/hacks, but it can be done now without having to wait. And it feels almost as fast as the stock.
yes i've also built one with the low-latency kernel and the MIB counters disabled, seems fine. brief ping stats:
--- 192.168.0.1 ping statistics ---
1037 packets transmitted, 1037 received, 0% packet loss, time 208020ms
rtt min/avg/max/mdev = 1.252/1.477/6.930/0.315 ms
i used to get max of 80+ms.
Now the real problem is push all to openwrt master...
And also increased kernel partition and dissent patch about cache scaling
The same here. I am also seeing great improvements to the ping latency over wifi.
Agree, and the first step could to have everyone interested to add comments to the PRs explaining the benefits of merging them. The more people are interested and benefited, the more likely they will be merged.
Here is a list of changes that I think makes this router great again.
- https://github.com/openwrt/openwrt/pull/632
- https://github.com/openwrt/openwrt/pull/669
- https://github.com/openwrt/openwrt/pull/848
- https://github.com/openwrt/openwrt/pull/849
- O2 or O3 optimization: https://gist.github.com/fantom-x/58fe0e1bb6534d73e6f3820e41423239
- A 4MB kernel partition as per https://github.com/dissent1/r7800/commit/18b149dbbcd744fad7dd35f7e45bc9b559eda8ef
- Disable mib counters as per this thread findings: https://gist.github.com/fantom-x/85f7841ecdbf9f111ff38ca1822c0a79
- Disable Export mac80211 internals in DebugFS followed by disabling DebugFS in kernel. This seems to have a positive impact on the wifi pings, but I do not know what it could have broken
An independent verification is required. https://gist.github.com/fantom-x/78564320f785b977b6058f9c08ece49e - option cache size 50000 for DHCP as the default is 150 only: this thing has a lot of RAM to handle more entries.
- If using SQM, then only move eth0 to CPU1. SQM is very CPU intensive (much more than the wifi interface) so let's let SQM use it all. I leave eth1, wifi0, and wifi1 on CPU0 for this reason.
UPDATE
- Make collectd (https://github.com/openwrt/packages/pull/5875), nlbwmon (https://github.com/openwrt/packages/pull/5876), and uhttpd run with lowest priority
- Use performance scaling governor for both cores: helps with wifi latency too. In the absence of any hardware acceleration and considering that the cpu is taking 100us to switch frequencies, this is a good stop-gap solution.
5 Likes