Is it normal that scaling_min_freq are different below?
cat /sys/devices/system/cpu/cpufreq/policy?/scaling_min_freq && cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_min_freq
1725000
1725000
384000
384000
I do not know if it is wrong or not, but seems inconsistent: cpu1: 1100mV while cpu0: 1150mV. I see this with both performance and ondemand (min/max cpu freq set to 1.75GHz). In either case, mem access speed is always in the low 600MB/s.
s1a 0 2 0 1150mV 0mA 1050mV 1150mV
cpu1 1100mV 1150mV
cpu0 1150mV 1150mV
About the voltage... it's not an issue. L2 is shared between the 2 cores and is set based on the max frequency of both... So it's just a visual bug as in reality it should be set to the right voltage.
I don't have android devices, so can't help. I do see you are using 80211w. Am wondering if the Android device has issues with that. You could try testing without it for a while.
And does the fact that it is using a dummy regulator have any influence? I would have expected the actual regular name instead. But i'm a complete novice on this stuff.
I have tried disabling 802.11w, but that didn't help. A while back Ben told me via email that he would have to buy the device himself to debug the issue and that it would require a lot of time, which he doesn't have. I was hoping that other people also would have this issue as that would give Ben some more incentive to look into it.
Hi,
Just to say that I installed 19.07.0 on a brand new R7800 and everything seems to be fine. I only use the device as a dumb AP so I can't talk much about the NAT performance but I can say that over AC WiFi I can reach reasonable bitrates in the LAN:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 398 MBytes 333 Mbits/sec sender
[ 4] 0.00-10.00 sec 398 MBytes 333 Mbits/sec receiver
Latencies look alright, too.
For info in case somebody was aware of it, there might be a little bug when booting up the system with two radios set to auto-select the channel. I haven't spent much time debugging it but the system ended up with a disabled 5 Ghz radio after the boot process:
Sun Jan 12 10:39:06 2020 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
...
Sun Jan 12 10:39:20 2020 daemon.err hostapd: ACS: Failed to request initial scan
Sun Jan 12 10:39:20 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Configured channel (0) not found from the channel list of current mode (2) IEEE 802.11a
Sun Jan 12 10:39:20 2020 daemon.warn hostapd: wlan0: IEEE 802.11 Hardware does not support configured channel
Sun Jan 12 10:39:20 2020 daemon.err hostapd: Could not select hw_mode and channel. (-3)
Sun Jan 12 10:39:20 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Sun Jan 12 10:39:20 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Whereas the 2.4Ghz radio was up and running. I had to manually restart radio0 (5 Ghz) using the web interface and everything worked after:
Sun Jan 12 10:43:22 2020 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
Sun Jan 12 10:43:22 2020 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->ACS
Sun Jan 12 10:43:22 2020 daemon.notice hostapd: wlan0: ACS-STARTED
Sun Jan 12 10:43:37 2020 daemon.notice hostapd: wlan0: ACS-COMPLETED freq=5580 channel=116
Sun Jan 12 10:43:37 2020 daemon.notice hostapd: wlan0: interface state ACS->HT_SCAN
Sun Jan 12 10:43:38 2020 daemon.notice hostapd: wlan0: interface state HT_SCAN->DFS
Sun Jan 12 10:43:38 2020 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5580 chan=116 sec_chan=1, width=1, seg0=122, seg1=0, cac_time=60s
Sun Jan 12 10:44:40 2020 daemon.notice hostapd: wlan0: DFS-CAC-COMPLETED success=1 freq=5580 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5610 cf2=0
Thanks for all the effort!
What kind of ping latency is normal between a wifi client and AP? With a Mac client close to the AP I see about 2-3ms with some periodic spikes to 10ms or even higher. Does this sound normal? 2.4 or 5GHz doesn't make a difference they both behave the same. Not sure where those spikes come from, could be the client doing something on a periodic basis like scanning, etc.
I get stats like this, numbers "all over the place" to use a scientific term:
113 packets transmitted, 113 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.541/7.508/109.347/12.824 ms
No obstacles, 5 Ghz, idle network:
100 packets transmitted, 100 received, 0% packet loss, time 99103ms
rtt min/avg/max/mdev = 0.821/1.570/3.771/0.442 ms
The client is an Intel AC 8260 (Asus PCE-AC55BT-B1).
Disable location on your Mac and test again
That seems to help a bit, though initially it didn't look like it. It seems that I have stable pings if there is other activity on the network regardless of location services, e.g. a TM backup over wifi.
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.436/2.961/7.590/1.134 ms
The connection looks very good, I can keep vpn and ssh connections open for days. It's just this latency variance that doesn't seem normal. I don't really have other clients to test with, just phones but those are all over the place with their power saving.
I think so. The memory test turned out to be very sensitive to any kind of load on the router. With WAN disconnected, wifi down, and all services stopped it gets over 780MB/s all the time. I traced my issue to dnsmasq of all things. I had it running with adblock and over 500K blacklisted domains: even with no load, dnsmasq would use 100% CPU for a few seconds every two or three seconds. The test was probably getting interrupted too frequently.
Here are the results without adblock.
./mbw 32 | grep AVG
AVG Method: MEMCPY Elapsed: 0.04241 MiB: 32.00000 Copy: 754.503 MiB/s
AVG Method: DUMB Elapsed: 0.18157 MiB: 32.00000 Copy: 176.242 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04290 MiB: 32.00000 Copy: 745.921 MiB/s
1 Like
Would be interesting to see with unbound-deamon only installation....
MacOS does periodic (and very frequent in my mind) WiFi scans for location purposes and the latency jumps to 300ms and more. I wish there was a way to disable those wifi scans.
@fantom-x if you want to test an improved version...
This should be the best we can do with the scaling... (I think i can't really optimize more)
2 Likes
Is there something different in 4.19 that the wireless interrupts cannot be moved from cpu0?
There must be and it is not platform specific: I have a spare ipq40xx and the ath10k IRQ's cannot be moved.
1 Like
Is it just the last commit?
UPDATE: it applies with warnings below
warning: squelched 6 whitespace errors
warning: 11 lines add whitespace errors.
Probably not much representative, because I am using the perf governor, WAN is disconnected, wifi and most services are down. Nothing weird in the logs, so I will put it on the live router shortly.
for i in 1 2 3 4 5 ; do ./tools/mbw 32 | grep AVG; done
AVG Method: MEMCPY Elapsed: 0.04188 MiB: 32.00000 Copy: 764.139 MiB/s
AVG Method: DUMB Elapsed: 0.18183 MiB: 32.00000 Copy: 175.984 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04207 MiB: 32.00000 Copy: 760.702 MiB/s
AVG Method: MEMCPY Elapsed: 0.04217 MiB: 32.00000 Copy: 758.808 MiB/s
AVG Method: DUMB Elapsed: 0.18349 MiB: 32.00000 Copy: 174.399 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04242 MiB: 32.00000 Copy: 754.304 MiB/s
AVG Method: MEMCPY Elapsed: 0.04202 MiB: 32.00000 Copy: 761.580 MiB/s
AVG Method: DUMB Elapsed: 0.18188 MiB: 32.00000 Copy: 175.942 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04220 MiB: 32.00000 Copy: 758.274 MiB/s
AVG Method: MEMCPY Elapsed: 0.04240 MiB: 32.00000 Copy: 754.778 MiB/s
AVG Method: DUMB Elapsed: 0.18360 MiB: 32.00000 Copy: 174.295 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04271 MiB: 32.00000 Copy: 749.279 MiB/s
AVG Method: MEMCPY Elapsed: 0.04208 MiB: 32.00000 Copy: 760.418 MiB/s
AVG Method: DUMB Elapsed: 0.18190 MiB: 32.00000 Copy: 175.924 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04224 MiB: 32.00000 Copy: 757.517 MiB/s
1 Like