The download speed indicator is stuck showing 2 GiB/s. When the applet is opened, it initially shows zero and then jumps to 2 GiB/s and remains there. Upload speed appears to be indicated correctly.
Please add some screenshots to the bug report. Also does the speed show up correctly under the interface name? Are you using wifi or ethernet? Were you able to test with any other network speed application if the hardware is reporting it correctly?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
My guess is that the problem lies in integer overflow. As far as I could deduce, the transmission speeds are calculated continuously by a timer in ConnectionItem QML component. This is done by subtracting the current value of rxBytes reported by the model from prevRxBytes stored as a property of the timer. The model uses qulonglong for the values of transmitted bytes but the QML component uses 32bit ints. I don't know how exactly Qt handles 64 -> 32 bit conversions when it passes data to QML but I suspect that if the actual number of rxBytes is greater than 2^31, then RxBytes - prevRxBytes exceeds the integer range and gets clamped to 2^31. When I reproduced the problem today, value reported from "cat /sys/class/net/wlan0/statistics/rx_bytes" was 3560443876 which is greater than what a signed 32 bit integer can represent. It also explains why the issue is difficult to reproduce; the NIC must receive over 2 GiB of data for the problem to occur.
I rebooted the computer to reset the kernel counters and then waited till rx_bytes ticks over 2^31. The problem immediately reappeared.
I am not able to reproduce this in plasma 6. Likely fixed by https://invent.kde.org/plasma/plasma-nm/-/commit/7ef8d079d1ce97b1d342f4ebf8691e014710e060. It uses real for rxSpeed now in qml instead of int. Can you verify.
(In reply to Shubham Arora from comment #5) > I am not able to reproduce this in plasma 6. Likely fixed by > https://invent.kde.org/plasma/plasma-nm/-/commit/ > 7ef8d079d1ce97b1d342f4ebf8691e014710e060. It uses real for rxSpeed now in > qml instead of int. Can you verify. I'm afraid I don't quite follow. The commit you reference is from 5 months ago and, as far as I can determine, it was part of Plasma 6 Beta 1 against which I reported the bug. The commit also does the exact opposite to what you say, it replaces reals with ints which is the actual cause of the problem. If I wait for the problem to occur, hot-edit ConnectionItem.qml to use reals for the prev[RT]xBytes and restart Plasma, the problem goes away. If I change the types back to ints, the problem reappears. This happens on Plasma 6.0.1.
I can reproduce this at will in Plasma 6. So, not fixed by that commit for me.
*** Bug 482855 has been marked as a duplicate of this bug. ***
*** Bug 483303 has been marked as a duplicate of this bug. ***
I believe I'm seeing the same bug on Plasma 6.0.2. I added a screenshot of the NetworkManager widget's speed graph that shows my WiFi speed as 10 GiB/s
Created attachment 167224 [details] Widget showing network speed as 10 GiB/s
For those who can reliably reproduce the issue, can you try the following hack to confirm the problem? 0) Wait for the problem to occur. 1) Locate the "ConnectionItem.qml" file, on my system it is in "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/contents/ui" 2) Open the file and confirm that lines 234 and 235 say property int prevRxBytes: 0 property int prevTxBytes: 0 3) Change the "int" to "real" on both lines, save the file and restart Plasma. The problem should disappear immediately. Note that you'll have to edit the file as root.
Created attachment 167283 [details] Screenshots of before and after changing 'int' to 'real' Seems to be working for me so far. See attachment.
(In reply to madcatx from comment #12) > For those who can reliably reproduce the issue, can you try the following > hack to confirm the problem? > 0) Wait for the problem to occur. > 1) Locate the "ConnectionItem.qml" file, on my system it is in > "/usr/share/plasma/plasmoids/org.kde.plasma.networkmanagement/contents/ui" > 2) Open the file and confirm that lines 234 and 235 say > > property int prevRxBytes: 0 > property int prevTxBytes: 0 > > 3) Change the "int" to "real" on both lines, save the file and restart > Plasma. The problem should disappear immediately. > > Note that you'll have to edit the file as root. Looks like this fixed it, thanks!
Git commit ba505d0d93629645d928087fddfc941773af086a by Kai Uwe Broulik. Committed on 16/03/2024 at 10:37. Pushed by broulik into branch 'master'. Use "double" for storing received/sent bytes An int can overflow and lead to negative and nonsensical speed values. M +3 -2 applet/contents/ui/ConnectionItem.qml https://invent.kde.org/plasma/plasma-nm/-/commit/ba505d0d93629645d928087fddfc941773af086a
Git commit 9dd7b54936b76e6e06ca1318c2932bb7ea42007a by Kai Uwe Broulik. Committed on 16/03/2024 at 11:49. Pushed by broulik into branch 'Plasma/6.0'. Use "double" for storing received/sent bytes An int can overflow and lead to negative and nonsensical speed values. (cherry picked from commit ba505d0d93629645d928087fddfc941773af086a) M +3 -2 applet/contents/ui/ConnectionItem.qml https://invent.kde.org/plasma/plasma-nm/-/commit/9dd7b54936b76e6e06ca1318c2932bb7ea42007a
*** Bug 483775 has been marked as a duplicate of this bug. ***