Bad WIFI after June update

Since last update, WIFI performance drop down 2 minutes after I start my vero2. Before, I have around 40 Mbit/s. After 2 min, there is only around 10 Mbit/s. When I reinstall OSMC with OSMC_TGT_vero2_20200402.img, the problem disappeared. Updating to June did not worsen WIFI-performance, as long I did not reboot the vero.

Logs: https://paste.osmc.tv/osuwovofev

Thomas

Hi @lichtus

I can’t think of anything that would have changed here.

When you uploaded this log, was the WiFi performance degraded?
How are you getting these WiFi performance results?

Hi Sam,

I uploaded the logs shortly after WiFi performance degraded. Wifi performance was tested with iperf3. When I watch a HD-Recording, the first two minutes after I start/reboot the vero are ok. After that, there is a lot of buffering. I found it strange myself, because nothing had changed regarding Wifi (Kernel, firmware, wpa_supplicant). I do some more testing tomorrow, go back to march and update step by step.

Thomas

Hi Sam,

it seems, that perftune-osmc is causing the trouble. In a second try, I went back to the march update, wich restored a good Wifi-performance. Then I tried to update step by step followed by a reboot:

armv7-network-osmc: performance ok
perftune-osmc: bad Wifi

Thomas

Now, I am back on the june update with the exception, that I have overwritten the file /usr/bin/performance_tuner with the version from github 23. Mar. All is working near perfect.

Thomas

I’d like to chime in on this and note that my Vero 4K is connected via wifi and I too am having constant buffering issues since the latest update. Not sure if it’s related to the issue mentioned here or not. There are no problems if I connect via Ethernet instead.

I would suggest creating a new thread in the appropriate subforum if you do wish to obtain support. This thread is specifically referencing a Vero 2 and unlikely to be related.

1 Like

My bad. Will do.

Hi Sam,

in your last version of performance_tuner you add some redirections. If you do so, you send the values to /dev/null instead to the sys-paths.

It is very discouraging, that after all my work (reinstall the vero 2 times, …) no one did notice this thread further.

Thomas

I haven’t been able to reproduce an issue related to WiFi caused by the CPU governor. There are also no changes to the active governor in this version.

I would suggest that the problem lies elsewhere. But you could check the active governor when the WiFi is responsive vs when it is not.

The thread was on my todo list, but it is a very busy time here at the moment

Hi Sam,

without this modifications, everything is fine. I have tried it several times.
With your modification: scaling_govenor -> performance -> bad wifi
Without: scaling_governor -> ondemand -> wifi ok

Thomas

The scaling governor should only run at performance for 60 seconds during boot, then should drop down to on demand. Can you verify this is the case?

Sam

Hi Sam,

you are right, the governor changed from performance to ondemand in both cases.
In my opinion: All lines with the /dev/null redirection, except the ‘change govenor line’ are disabled, causing bad wifi somehow. I can easily reproduce that by changing the version of performance_tune and reboot.

Thomas

I will check this.

Dear Sam,

since the october update, WIFI-problems are back again, because you did not fix performance_tuner. A possible solution is to use brackets like this:

if [ ! -f /safe_mode ]
then
	# 30 seconds of accelerated boot. we set curgov to ondemand so the next check only doesn't flip us back if we had performance to begin with
	sleep 30
	echo "ondemand" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > /dev/null 2>&1 #all platforms
	(echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold) > /dev/null 2>&1
	(echo 100000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate) > /dev/null 2>&1
	(echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor) > /dev/null 2>&1
	(echo 50 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/up_threshold) > /dev/null 2>&1
	(echo 100000 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate) > /dev/null 2>&1
	(echo 50 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/sampling_down_factor) > /dev/null 2>&1
	else
		echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > /dev/null 2>&1
fi

Greetings

Thomas

Hi Thomas,

Thanks for your prompt feedback.

Unfortunately I could not reproduce the issue first hand and we haven’t had other reports.

With that said, you should be able to safely revert back the changes so that the file is as before. We won’t be able to support the Vero 2 after Kodi v19, so this will be the last version supported.

Thanks

Sam

Dear Sam,

as I say in my post earlier, your changes in performance_tuner to silence error messages send all values to /dev/null. Please check the values in /sys/… Enclosing the code in brackets make it working again and silence error messages.

Thomas

Hi Thomas,

I see your point now. Thanks for pointing this out.
I have pushed a solution.

Can you please update again and check it?

Sam

Hi Sam,

the problem is solved now.

Best regards

Thomas

Thanks for confirming.