On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays. The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates. My own system (different laptop so not the same hardware) with basically the same versions of all software does not exhibit this behavior. I'm not sure where to start looking. X is whatever the default would be as the result of a Tumbleweed install. My daughter's install is a couple years old. It has been fine up to the update done in late December. All updates since then are also installed, but they have not helped. Any suggestions where to look? As I seldom have trouble, I confess that I'm a bit rusty at this type of thing. I googled the clock thing but I did not find much. Of course, it may not even be the clock part that is the real problem... -- Roger Oberholtzer
Hi Roger, We ask people who are using Tumbleweed to subscribe to the factory mailing list and respond to the snapshot that is updated with a a subject title of the issue. The factory mailing list is here - https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/ The support email list (https://lists.opensuse.org/archives/list/support@lists.opensuse.org/) can also be used, but there appears to be a difference of hardware from the sounds of it. I would recommend sending an email to the support mailing list along with the nature of the problem, which you listed, model and hardware info of your daughter's laptop. You could also send to both the support and factory list. Odds are someone will help and if it's a bug, in either Tumbleweed or KDE, it will be made known to the correct people. v/r Doug On 1/18/21 1:47 PM, Roger Oberholtzer wrote:
On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays.
The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates.
My own system (different laptop so not the same hardware) with basically the same versions of all software does not exhibit this behavior.
I'm not sure where to start looking. X is whatever the default would be as the result of a Tumbleweed install. My daughter's install is a couple years old. It has been fine up to the update done in late December. All updates since then are also installed, but they have not helped.
Any suggestions where to look? As I seldom have trouble, I confess that I'm a bit rusty at this type of thing. I googled the clock thing but I did not find much. Of course, it may not even be the clock part that is the real problem...
-- Roger Oberholtzer
Hi Doug On 1/19/21 12:31 AM, ddemaio wrote:
Hi Roger,
We ask people who are using Tumbleweed to subscribe to the factory mailing list and respond to the snapshot that is updated with a a subject title of the issue. The factory mailing list is here - https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/
This information is out of date for the last 2 years, we now ask that people leave the factory list for development discussions. Instead they should report a bug at bugzilla.opensuse.org or if they are not sure if it is a bug worth reporting they can seek help on the support list as you suggest. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tuesday 19 January 2021, Roger Oberholtzer wrote:
On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays.
The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates.
My own system (different laptop so not the same hardware) with basically the same versions of all software does not exhibit this behavior.
I'm not sure where to start looking. X is whatever the default would be as the result of a Tumbleweed install. My daughter's install is a couple years old. It has been fine up to the update done in late December. All updates since then are also installed, but they have not helped.
Any suggestions where to look? As I seldom have trouble, I confess that I'm a bit rusty at this type of thing. I googled the clock thing but I did not find much. Of course, it may not even be the clock part that is the real problem...
Have you investigated whether there might be a recent hardware issue/fault? Perhaps good memory has gone bad, a disk/ssd is on the way out, a dust or fan failure is overheating something. I once had some issues with my partner's machine until I reseated the graphics card. I would take a browse through the messages from dmesg and journalctl --boot and smarctl. I'd check the temperatures (and voltages too if you undersand that stuff). Does a portable boot from SSD/DVD distro run cleanly? I haven't run memtst86 in many years, but maybe it's still relevant. I'm running TW/KDE on two desktops and they are quite solid. In the case of a laptop I might take a look at KDE's powersaving settings; what happens before/after Sleep/Hybernate; and whether the GPU driver might be inappropriate. I presume you're still on X11 and not Wayland - Wayland is very flaky for me (mutli-monitor and Nvidia user). Best of luck.
On 1/18/21 6:47 AM, Roger Oberholtzer wrote:
The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates.
Roger, If you have checked top and nothing is spinning out of control, then there is likely an old config bit or problem with KDE there. With KDE5/Plasma, there have been several additional "nanny" layers that provide automatic formatting and font sizing put in place that are supposed to maintain the systray widgets in the proper (KDE chosen) size and format. If there is a bit of an old config or setting related to the clock or systray, it could very well be giving the nanny layer logic fits. There isn't any direct way a user can set the clock font-size, etc.. anymore (other than hacking), so if the problem persists and you don't have some identifiable process spinning out of control, then following what ddemaio suggest is probably the best path. You know, the subscribe to yet another fragmented list so you can retype your problem and send it there for what used to be able to be handled here. Personally, I think pushing people to the factory list for bug questions is the wrong approach. Factory was supposed to be forward-looking working on upcoming changes, not backwards looking at current bugs, but when you have so many lists to choose from -- who knows anymore... -- David C. Rankin, J.D.,P.E.
On 1/19/21 2:20 PM, David C. Rankin wrote:
On 1/18/21 6:47 AM, Roger Oberholtzer wrote:
The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates.
Roger,
If you have checked top and nothing is spinning out of control, then there is likely an old config bit or problem with KDE there. With KDE5/Plasma, there have been several additional "nanny" layers that provide automatic formatting and font sizing put in place that are supposed to maintain the systray widgets in the proper (KDE chosen) size and format. If there is a bit of an old config or setting related to the clock or systray, it could very well be giving the nanny layer logic fits.
There isn't any direct way a user can set the clock font-size, etc.. anymore (other than hacking), so if the problem persists and you don't have some identifiable process spinning out of control, then following what ddemaio suggest is probably the best path.
You know, the subscribe to yet another fragmented list so you can retype your problem and send it there for what used to be able to be handled here. Personally, I think pushing people to the factory list for bug questions is the wrong approach. Factory was supposed to be forward-looking working on upcoming changes, not backwards looking at current bugs, but when you have so many lists to choose from -- who knows anymore...
I have what may be the same problem on a Ryzen/16GB RAM machine running Leap 15.1 and KDE Plasma 5.12.8. The digital clock showing seconds & date will jump several seconds at a time or get jittery or it will hang until I click on it. Additionally, when this happens the Task Manager app tabs will sometimes also become jittery and hang up trying to move in the panel after an apps is opened or closed, until I click on the clock which settles it all down. This behavior seems to happen when I have Chrome open with several windows & 100+ tabs, along with T'bird and 6-10 apps. KsysGuard shows very little CPU load and RAM usage is ~14GB (out of 16GB) with 250MB of swap, so it isn't the hardware. I suspect Plasma or the compositor is the culprit, but I haven't researched it because for me (unlike your daughter) its a small annoyance easily worked around with a click on the clock. (Although this has made me late for dinner more than once.) I suggest you try changing up the desktop mix, i.e., reducing the mix and number of apps to see if that changes the behavior or turning off the compositor or trying a different desktop manager. --dg
On Wednesday 20 January 2021, David C. Rankin wrote:
On 1/18/21 6:47 AM, Roger Oberholtzer wrote:
The clock update is useful when she is taking remote exams (at the University). Also, after the update, programs like zoom have become unstable. Zoom itself was not updated. But all else has been as part of the usual Tumbleweed updates.
Roger,
If you have checked top and nothing is spinning out of control, then there is likely an old config bit or problem with KDE there. With KDE5/Plasma, there have been several additional "nanny" layers that provide automatic formatting and font sizing put in place that are supposed to maintain the systray widgets in the proper (KDE chosen) size and format. If there is a bit of an old config or setting related to the clock or systray, it could very well be giving the nanny layer logic fits.
...
If it's a config issue if should go away for a freshly created user. For example, my launcher's digikam icons sometimes disappear, but this doesn't happen to my newly created tumb1 test account, so my problem is very likely being caused by some config conflict of the nature you've described. However I wouldn't discount the possibility that the OP's problem might be hardware or possibly graphics-driver related, so as I previously suggested I would first check dmesg and journalctl. It also might be worth checking the user's .local/share/sddm/xorg-session.log
On 2021/01/18 04:47, Roger Oberholtzer wrote:
On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays.
I don't really know what is going on, but it sorta sounds like the clock process + display isn't being updated regularly. An interesting data point would be opening a reliable terminal instance, and in that, run a clock that displays at a fixed interval. Attached script can allow fiddling with initial delay & per_loop. Hit control-c to exit. See if this timer varies much -- the main point is to have each cycle vary by about 1 second. If it is delaying too long or whatever, you can see if it is the clock or if it is the display that not being consistent. Something in me says either power-saving functions or something limiting cpu cycles. I think systemd can do the latter, like limit a process to x% of some resource. Might do the former, but dunno -- could just be your power-save settings got changed. I was amazed at how, if I followed the powersave suggestions, how bad it made my USB-keyboard's response time. Basically I set that for never to goto sleep since sleeping USB threw off my ability to engage key-repeat reliably. Make sure power-saving features aren't clicking in, and by default, I don't think it would be a systemd feature. Maybe some other process is hogging the cpu periodically? Might also try running these tests as root and doing a nice -19 on the scripts while you run, though shouldn't be normally necessary unless something is stealing time. That's all I can think of offhand. Oh might make sure your scheduler algorithm is set to on_demand, and not something like power-saving (assuming her laptop is plugged in during all this). Good luck! -linda #!/bin/bash shopt -s expand_aliases alias my='declare ' int='my -i ' my init_delay_reduction="5000000" my per_loop="0.9966" tsync() { int t=2000000000-$(date +"1%N")-$init_delay_reduction sleep $(printf "%5.3f" "0.$t") } disptime() { my h m s read h m s< <(date +"%H %M %S.%09N") printf "%s:%s:%04.1f\n" "$h" "$m" "$s" } tsync sleep .5 tsync while :;do disptime sleep $per_loop done
On 20/01/2021 07.05, L A Walsh wrote:
On 2021/01/18 04:47, Roger Oberholtzer wrote:
On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays.
I don't really know what is going on, but it sorta sounds like the clock process + display isn't being updated regularly.
An interesting data point would be opening a reliable terminal instance, and in that, run a clock that displays at a fixed interval. Attached script can allow fiddling with initial delay & per_loop. Hit control-c to exit.
See if this timer varies much -- the main point is to have each cycle vary by about 1 second. If it is delaying too long or whatever, you can see if it is the clock or if it is the display that not being consistent.
Something in me says either power-saving functions or something limiting cpu cycles. I think systemd can do the latter, like limit a process to x% of some resource. Might do the former, but dunno -- could just be your power-save settings got changed.
There are two modes for the clock sluggishness. Let's say the clock display doesn't update every second; say it would suddenly stay still for 3 seconds, but when it updates it jumps 3 seconds, so the time would be correct. Or, say, it increases one second, losing time. Which of them is it? This is important to know. If it loses time, it can kernel issue (check in text mode). If it keeps time, but jumps, it is an application or desktop issue. I had a worse problem years ago, with another computer. Not my previous desktop, but the one before, with openSUSE 10.3. It was a kernel issue; the root cause was not found. The machine would freeze completely, nothing would update; but touch a key, move the mouse, get a network package (anything generating a hardware interrupt) and it would resurrect. The clock lost count of time, maybe a minute, ocassionally half an hour. ntp failed. The CPU was asleep during that time, but an IRQ would wake it up (Bugs 344356, 350980 and 350981). -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Roger Oberholtzer wrote:
On an up-to-date Tumbleweed computer, my daughter now has trouble with things like the clock in the KDE status bar. She suspected that it was not updating properly so she turned on showing seconds. And she sees that it is very uneven about when time is updated. We have looked at the processes running and the memory and swap usage. I cannot see anything that would explain such delays.
Not sure if it's related. I did (and do) have issues with long-running applications suddenly not updating the screen anymore. Mostly affected in my case is gkrellm. The culprit there seems to be the compositor. At least, if I switch it off (Shift-Alt-F12) updates are fine again (and stay OK if I then re-enable it).
participants (9)
-
Carlos E. R. -
David C. Rankin -
ddemaio -
DennisG -
L A Walsh -
Michael Hamilton -
Peter Suetterlin -
Roger Oberholtzer -
Simon Lees