[I] <dsimic> but with the SoCs, such a concept is pretty much not common, which is why I think it wouldn't be accepted upstream
Читать полностью…[I] <dsimic> which perhaps comes from the fact that adjusting the frequencies and voltages on GPUs has been around since (more modern) GPUs existed, basically
Читать полностью…[I] <dsimic> but I still think that such an interface wouldn't be accepted upstream, and that some kind of a DT overlay editor would be a better choice
Читать полностью…[I] <dsimic> was there some file or picture? they disapper from messages coming from Telegram while crossing the bridge
Читать полностью…[I] <megi> there are some patches that are not upstream that may be worth trying for you https://github.com/airtower-luna/linux/commits/rtw88_8723cs-optimize (I tried, there are still issues, there are also some issues with queueing packets for TX, which show up when doing UDP iperf3 test with TX speeds over what network can handle)
Читать полностью…[I] <dsimic> you don't need to be subscribed, and you can get the messages to reply to from the public inbox
Читать полностью…[M] <piggz> i can do it, but im not currently subscribed, so happy for someone who is to take that on
Читать полностью…[I] <dsimic> hmm, how can we differentiate between lower speed, stuttering and poor performance in general?
Читать полностью…I think it's not something new. megi wrote about limited upstream driver performance https://xnux.eu/log/097.html
Читать полностью…[I] <dsimic> @piggz : hmm, maybe you could try sending all this information to the mailing list, in the thread that introduced the upstream WiFi driver?
Читать полностью…[I] <dsimic> so people are used to fiddling with those and, many times, getting some artifacts and whatnot :)
Читать полностью…[I] <megi> driver author knows of the issues, it's just not clear how to solve them
Читать полностью…[I] <dsimic> but again, I think that providing feedback to the author of the upstream driver can only be helpful
Читать полностью…[M] <Andrey Skvortsov> and I see poor performance of upstream driver as well on 6.12.
Читать полностью…[I] <dsimic> I might be able to have a look into all that, but I'm really not sure when that might happen
Читать полностью…[M] <piggz> Watching logs I noticed something that might be useful for wlan driver developers.
Wifi is very faulty (I know... I'm redundant...).
I have many of theese before connection occurs:
-
Sep 06 00:19:12 PinePhone wpa_supplicant[2886]: wlan0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='my-SSID' freq=2412 MHz)
Sep 06 00:19:13 PinePhone kernel: wlan0: authenticate with xx:xx:xx:xx:xx:xx (local address=yy:yy:yy:yy:yy:yy)
Sep 06 00:19:13 PinePhone kernel: wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Sep 06 00:19:13 PinePhone kernel: wlan0: send auth to xx:xx:xx:xx:xx:xx (try 2/3)
Sep 06 00:19:14 PinePhone kernel: wlan0: send auth to xx:xx:xx:xx:xx:xx (try 3/3)
Sep 06 00:19:15 PinePhone kernel: wlan0: authentication with xx:xx:xx:xx:xx:xx timed out
Sep 06 00:19:15 PinePhone wpa_supplicant[2886]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="my-SSID" auth_failures=1 duration=10 reason=CONN_FAILED
-
then, if connection happens, lots of theese:
-
Sep 06 00:22:39 PinePhone n-selector[5712]: [D] unknown:0 - Selected service "my-SSID" path "/net/connman/service/wifi_zzzzzzzzzzzz_zzzzzzzzzzzzzzzzzzzzzzzz_managed_psk"
Sep 06 00:22:39 PinePhone n-selector[5712]: [D] unknown:0 - Updating default route
-
and then tons of theese:
-
Sep 06 00:22:47 PinePhone wpa_supplicant[2886]: wlan0: CTRL-EVENT-BEACON-LOSS
-
data transfer eg. reading logs on ssh is always stuttering when not stopping.