@hnyman, related to the updated first post, are you sure the freq scaling,etc. is working?
I see that blogic has closed dissent1's PR (#632) but I cannot find this back in the github logs?
Or, was it all included when IPQ806x was moved to kernel 4.14 by R. Jangir?
CPU frequency scaling has worked since early 2017
EDIT:
the core part of CPU frequency scaling was implemented already in late 2016. See the first core commits here:
https://github.com/openwrt/openwrt/commits/b2135f3ba5f0ce3bac39620bcdfd46a0225727b5
and then in March 2017 I re-enabled the independent scaling of cores with
https://github.com/openwrt/openwrt/commit/3f9eadf599e7d44fe5c3e4c4652334dda4c6d88f#diff-3e975c9f8ed838b203874eac61a79f18
is it normal for bogomips to be different from one cpu to the other ( 26.95 and 56.15 ) when cpu scaling is disabled ( by compiling the kernel with ondemand disabled and performance as default governor ).
root@gateway:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 26.95
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x04d
CPU revision : 0
processor : 1
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 56.15
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x04d
CPU revision : 0
Hardware : Generic DT based system
Revision : 0000
Serial : 0000000000000000
root@gateway:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1725000
root@gateway:~# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq
1725000
root@gateway:~#
Bogomips really are bogus, there have been attempts to remove it completely - the only reason why they had to be reintroduced was to keep old/ broken userland 'working'.
I decided to test the performance I get with cake - layered_cake. This is what I get on my Archer C7 v2 after flashing blogic's mac80211 patch build:
This is what I get on my R7800 with blogic's patch:
Both tests were done with only the internet connection set up and sqm configured (no wifi, apps, etc.)
I've always had a feeling that the speeds I get on my R7800 have been very wonky, and the Archer C7 v2 should definitely not get better speeds than the R7800 considering the difference in CPU power. Is it possible that ath79 provides enough of a performance boost to enable the Archer to outperform the R7800?
You might test tweaking the CPU frequency scaling ramp-up parameters in kernel.
See
I tried:
echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
The speeds improved, but they're still on the low side (I have a 500/500 line):
I also tried irqbalance together with the changes above without any improvement (a decrease in upload speed in fact):
root@telia:~# cat /proc/interrupts
CPU0 CPU1
16: 12515 26923 GIC-0 18 Edge gp_timer
18: 33 0 GIC-0 51 Edge qcom_rpm_ack
19: 0 0 GIC-0 53 Edge qcom_rpm_err
20: 0 0 GIC-0 54 Edge qcom_rpm_wakeup
26: 0 0 GIC-0 241 Edge ahci[29000000.sata]
27: 0 0 GIC-0 210 Edge tsens_interrupt
28: 17033 447 GIC-0 67 Edge qcom-pcie-msi
29: 20342 5607 GIC-0 89 Edge qcom-pcie-msi
30: 121442 0 GIC-0 202 Edge adm_dma
32: 391151 395 GIC-0 258 Level eth1
33: 0 0 GIC-0 130 Level bam_dma
34: 0 0 GIC-0 128 Level bam_dma
35: 0 0 PCI-MSI 0 Edge aerdrv
36: 17033 447 PCI-MSI 1 Edge ath10k_pci
68: 0 0 PCI-MSI 0 Edge aerdrv
69: 20342 5607 PCI-MSI 1 Edge ath10k_pci
101: 12 0 GIC-0 184 Level msm_serial0
102: 2 0 msmgpio 6 Edge gpio-keys
103: 2 0 msmgpio 54 Edge gpio-keys
104: 2 0 msmgpio 65 Edge gpio-keys
105: 0 0 GIC-0 142 Level xhci-hcd:usb1
106: 0 0 GIC-0 237 Level xhci-hcd:usb3
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 9839 5868 Rescheduling interrupts
IPI3: 33 33533 Function call interrupts
IPI4: 0 0 CPU stop interrupts
IPI5: 11286 6782 IRQ work interrupts
IPI6: 0 0 completion interrupts
Err: 0
Just to add my experience - Today I bought an R7800, went to the device's 192.168.1.1 address, and used their web interface to flash 18.06.1 (the factory.img file). Worked perfectly. There is a warning about "downloading to an older firmware" and you just click through that.
Thanks all.
I've been part of this thread for a while now and have really enjoyed learning and even helping some.
I recently moved to Michigan from Florida. In Michigan I now have a fiber connection (1000Mbps up and down) which is just incredible. However, I have now realized the limitation of our version of OpenWrt for the R7800. I cannot break 300Mbps over WiFi no matter what I do.
I switched to the Netgear stock firmware and easily hit 900Mbps.
I tried dd-wrt and easily hit 800Mbps.
So, I really want to help solve this for OpenWrt and I know that we have gotten close a few times. Do we know where the problem currently resides? Where is a good place to start looking for repairs in this area? Is it the Atheros firmware? I also realize that the number 1 contributor to this version of OpenWrt (@hnyman) doesn't have a super highspeed connection to test with so we might need some other peeps to step up if they can help.
Let's solve this if we can!
Thanks all.
The vendor firmware offloads most of the firewalling, NATing and routing to two dedicated 800 MHz NSS/ NPU cores, support for these (hardware flow-offloading) is not available in OpenWrt so far and the main SOC hits its limits around 350-400 MBit/s.
In contrast mvebu does have the performance to route at 1 GBit/s line speed in software, while mt7621 has supported hardware flow-offloading available to keep up with the easy cases.
What is dd-wrt doing to get past this?
As far as I can tell, Marvell does a lot of development to get it's Ethernet driver to be performant. Qualcomm does none.
from my own experience the R7800 CPU is more powerfull as the one in my WRT1900AC(S) V2. so i'm not so certain that the R7800 would actually be slower.
Wireless driver is definitively more stable as the WRT driver.
dd-wrt uses the Qualcomm SFE to accelerate traffic flow. With OpenWRT, you’ll have to build your own firmware to incorporate it. Or use the community builds who incorporated it.
Yes, the IPQ8065 does have a slight edge however it's very minor in most cases (raw CPU power). As far as WIFI goes, I'd say they're equal however there's a lot that can impact on WIFI performance which these radios handles differently. Keep in mind that drivers are just as important if not even more in terms of stability and performance.
How do you go about building firmware with Qualcomm SFE. I am using hnyman's build environment with his patches. Is it an option in make menuconfig?
Thank you.
I know MU-MIMO isn't supported (yet). Is there any way to get it working or do I have to wait until someone reverse engineers it?
Do any of your client devices support MU-MIMO already? Because if not it will not work.
Apparently even the vendor implementations do not really work/offer not real benefit.
With that background i wouldnt get my hopes too high to see it anytime soon in OWRT
Check SNB for some background.
Good point. I have some fairly new devices but now when I googled, it seems they support MIMO at most.
Hi, I'm running the OpenWrt 18.06-SNAPSHOT r7297-13dccfc8e4 build, and if I enable both 2.4GHz and 5GHz wifi simultaneously my R7800 just hard resets once clients connect. It just reboots, and then it works fine, until the clients connect again, which causes it to reset again.
I'm running out of things to try to debug this, do any of you maybe have an idea how to investigate this? I've tried all kinds of different configurations, and individually both 5GHz and 2.4GHz run well.
Since it just resets I'm not getting any handle on what might be wrong, I've tried running while true; do dmesg -c; done over a wired connection to try and get any output before it crashes, but nothing in there.
I've even tried using the ath10k-ct firmware, but with it it behaves exactly the same.
Any help would be greatly appreciated.
Config looks like this:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option channel '52'
option country 'US'
option legacy_rates '1'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'psk-mixed'
option key 'secret'
option wps_pushbutton '0'
option ssid 'OpenWrt5'
option disabled '1'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
option htmode 'HT20'
option country 'US'
option legacy_rates '1'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'psk-mixed'
option key 'secret'
option wps_pushbutton '0'
dmesg | grep ath looks like this, maybe you can spot something in there?
[ 18.377486] ath10k_pci 0000:01:00.0: assign IRQ: got 67
[ 18.377864] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142)
[ 18.377942] ath10k_pci 0000:01:00.0: enabling bus mastering
[ 18.378389] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 18.568383] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[ 18.568430] ath10k_pci 0000:01:00.0: Falling back to user helper
[ 18.595136] firmware ath10k!QCA9984!hw1.0!firmware-6.bin: firmware_loading_store: map pages failed
[ 18.708116] ath10k_pci 0000:01:00.0: Unknown FW IE: 30
[ 18.708143] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 18.712145] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 18.723700] ath10k_pci 0000:01:00.0: firmware ver 10.4-ct-9984-xtW-010-868495e api 5 features peer-flow-ctrl crc32 b68bff6b
[ 21.042564] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:1 crc32 dd6d039c
[ 26.865910] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
[ 26.956529] ath: EEPROM regdomain: 0x0
[ 26.956542] ath: EEPROM indicates default country code should be used
[ 26.956552] ath: doing EEPROM country->regdmn map search
[ 26.956571] ath: country maps to regdmn code: 0x3a
[ 26.956582] ath: Country alpha2 being used: US
[ 26.956592] ath: Regpair used: 0x3a
[ 26.961759] ath10k_pci 0001:01:00.0: assign IRQ: got 100
[ 26.962811] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142)
[ 26.962946] ath10k_pci 0001:01:00.0: enabling bus mastering
[ 26.963622] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 27.135905] ath10k_pci 0001:01:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[ 27.135936] ath10k_pci 0001:01:00.0: Falling back to user helper
[ 27.255579] firmware ath10k!QCA9984!hw1.0!firmware-6.bin: firmware_loading_store: map pages failed
[ 27.255729] ath10k_pci 0001:01:00.0: Unknown FW IE: 30
[ 27.263544] ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 27.268557] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 27.280507] ath10k_pci 0001:01:00.0: firmware ver 10.4-ct-9984-xtW-010-868495e api 5 features peer-flow-ctrl crc32 b68bff6b
[ 29.596422] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 dd6d039c
[ 35.409898] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
[ 35.495752] ath: EEPROM regdomain: 0x0
[ 35.495763] ath: EEPROM indicates default country code should be used
[ 35.495773] ath: doing EEPROM country->regdmn map search
[ 35.495789] ath: country maps to regdmn code: 0x3a
[ 35.495801] ath: Country alpha2 being used: US
[ 35.495810] ath: Regpair used: 0x3a