Hi
I noticed strange behavior with dramatically decrease in wireless network performance on my Vero 4k when Hyperion with enabled mDNS / SSDP services is running.
I found that when Hyperion is active, the wi-fi adapter every 10 seconds switches TX to slowest basic rate 6 mbps. Which in turn slows down all tcp connections in the system.
The dmesg log at this moment is full of messages about radio scan every 10 seconds :
[59086.985478] wl_run_escan: LEGACY_SCAN sync ID: 5909, bssidx: 0
[59096.985244] wl_run_escan: LEGACY_SCAN sync ID: 5910, bssidx: 0
[59106.985873] wl_run_escan: LEGACY_SCAN sync ID: 5911, bssidx: 0
[59116.986890] wl_run_escan: LEGACY_SCAN sync ID: 5912, bssidx: 0
A little more details in the hyperion-project issue: mDNS discovery dramaticaly decrease wi-fi performance on linux host · Issue #1712 · hyperion-project/hyperion.ng · GitHub
When I stop Hyperion service these 10-seconds scans and flappening stops, the wireless network continues to work perfectly full speed full time.
There is some problem between Hyperion, connmand and vero that produces periodical radio scan with an interface slowing. I’m not sure this is only Hyperion problem but can’t locate the source of the problem more accurate and will be gratefull for help with debug
Why does it need to be scanning every ten seconds?
Sam, unfortunately I have no idea!
I just run hyperion and then found connmand which continuously scanning radio. Please look on the test screenshot below: I ran iperf stream to the vero with and without runned hyperion. What can explain that behavior?
I think the QNeteork interface is doing this. Maybe it can be disabled by setting scan_interval to 0 via wpa_cli
QNetwork is a good suspect. But wpa_cli is not enougth to beat him:
osmc@vero:~$ sudo wpa_cli -i wlan0 scan_interval 0
OK
osmc@vero:~$ sudo wpa_cli -i wlan0 scan type=only
OK
And ten seconds scan is still active.
For now, I will simply disable mdns in hyperion and try to understand more deeply what is happening there separately.
Can I reproduce this without needing Hyperion (ie NVIDIA GPU)?
Hyperion in question is just led backlight software: GitHub - hyperion-project/hyperion.ng: The successor to Hyperion aka Hyperion Next Generation. There are no special requirements to run it.
To reproduce the problem you need to start hyperiond, builded with -DENABLE_MDNS=ON option.
You can use my vero4k binary (link). It is statically linked and seems like it should simply start.
Or you can quick built it with simple @hissingshark’s toolkit GitHub - hissingshark/hyperion-vero4k: Automated build and default install of Hyperion.ng on the Vero4K (OSMC) for required enviroment with ENABLE_MDNS.
There is no specific configuration required, in my case scanning begins after the start.
Not what I meant. I meant can it be reproduced without Hyperion running?
If so – it’s an OSMC issue, if not, it looks to be Hyperion related.
No, I can’t reproduce this without hyperion, it’s the only known app that causes continuous scanning.
I asked here because I thought that maybe this is some kind of corner case, related to osmc network.
Don’t know enough about the Qt networking stack to advise there.
Can you avoid mDNS and use fixed/assigned IP for your devices responsible for the Hyperion process?
Sam
The problem does not reproduces in the build with Qt6 instead of system’s Qt5.
Thank you for your hint about QtNetwork.
@yunihiko Can I clarify - was your workaround to build hyperion.ng using Qt6? By modifying the dependencies in my installer?
Hi! To build I used docker-compile.sh from hyperion-project’s own toolkit. They have prebuild Bullseye arm images with Qt6 enviroment. I wasn’t sure of success at the time and it seemed like a quick fix.
./docker-compile.sh --architecture arm/v7 --packages true --name bullseye -- -DPLATFORM=amlogic -DENABLE_AMLOGIC=ON
But there are Qt6 packages available in the bullseye-backports repository, and now I think it is possible to use them.
Also, note that the issue is not related to mDNS and I have reproduced it even on your latest binary build 2.0.15. Check dmesg | grep LEGACY_SCAN. I suspect SSDP on which many network led-devices depend on.
