What I see is sluggish UI behavior, for example dragging a window across the desktop, or hovering over a list. When dragging, the window lags way behind the cursor; when hovering it takes a perceptible amount of time for the item to highlight. Also benchmarks -- e.g. Blowfish gives a score around 38. This is after a fresh power-up boot.
It seems like someone, some process is holding interrupts disabled for too long a time.
But the good news is, that if I log off and back on, LL is delightfully quick and responsive with a Blowfish score around 16! This is very consistent, and I just discovered the log on/off sortof by accident.
I've been using htop and cpufreq-info looking for clues but no joy so far. Curiously when sluggish, Task Manager shows about 50% CPU usage (nothing else running) with Task Manager itself consuming most of that. When snappy, Task Manager shows only 4..5% CPU and again, Task Manager is responsible for most of that -- which seems most reasonable.
I submit this, wondering if anyone has similar experience, additional clues or a possible solution.
Thanks for listening.
Jim
Hello Jim,
I am wondering could it be the graphics driver ?
Which driver are you using ?
Do you have UFW (firewall) enabled ?
This fairly common behavior for Ubuntu, but is generally caused by the unattended updates (automatic update and automatic kernel removal) system. As far as I know LL uses manual kernel removal tools and does not run a full unattended updates version like Ubuntu, however the cause may still be backgrounded there. When you first login wait until the cpu usage drops off to a low figure, (single digit %). If it falls off and performs normally in a few minutes I expect update utilites are the most likely culprit. Use lite tweaks to remove old kernels and before your next update run: sudo apt-get update from the terminal, and then exit and update normally from the GUI. Also check syaptic for packages with broken dependencies.
TCÂ
Well, I've been trying this or that to nail it down, and the one reproducible step is that booting up from a power-off state triggers the problem. A reboot from the GUI, or log off/on it works fine.
Other things I've tried ...
Drivers -- no 3rd party drivers are installed.
Updates -- are set to manual and that was accomplished this morning picking up just a few things.
Originally it was set to auto-logon, so I edited lightdm.conf to turn it off and same problem.
Created a new user with same admin priviledges NO problem with or without auto-login.
Tried live boot from the USB and no problem.
Thinking that this is either a bug or user error, I tried sudo 'apt-get redemption', but that did not help at all
Seriously perhaps it is some UI tweak I've made or something I've installed.
Installations include Pale Moon, psensor, gqrx (rtl-sdr software) and think that's all. I could try backing those out...
Or I could try the restore point I made. Or I could re-install the whole thing. Or I could live with it 'cause when she is good she's very very good. LL has breathed new life into this old laptop.
regards
Jim
The radio software may be the culprit- gqrx (rtl-sdr software). Set it not to load on startup. You may have to use systemd to do so. Also check your session and startup menu to disable unneccessary startup items.
Also do you have the corrected port version since Deb 9 release? I would check Deb 8 and 9 backports to see if Deb 9 port is avaliable and change to Deb 9 for gqrx if upgrade is available.
TC
Moved to correct section.
Thanks Jerry, was not sure where this post belonged.
But think I've found a likely suspect, and it's wireless. After a powerup boot, if I toggle the wireless connection off and on, all is well. Same results as logging off/on.
If I disable wireless and power off/on. All is OK until I re-enable wireless. Then it becomes sluggy right away. If I then toggle wireless off/on all is well. All subsequent toggles are equally OK. It's the first toggle that does it.
Here is a step by step process to discovery. These were raw notes I was taking during the process and may not make much sense.
Fresh install with no updates -- no problem
Performed updates and on completion idle CPU usage around 50% before reboot. This with wireless connection. And it seemed sluggish.
Press reboot button -- OK and TaskManager shows single digit usage.
Power down / power up -- Sluggy -- TaskManager shows ~ 50% CPU usage -- mind you, nothing else is running but 'Welcome to Linux Lite' -- I touched nothing.
Log off/on -- all's well -- TaskManager once again shows single digits.
Ahah! I disabled networking -- on power up all is well.
Enabled networking -- wireless still disabled -- All OK.
Re-enabled wireless -- NFG
Plugged in Cat5 instead of wireless -- All OK.
Unplugged Cat5 -- no wireless -- powerup boot All OK.
But connected WIFI -- NFG right away
Disabled WIFI -- All OK
Repeat -- same results
Now gonna try toggling WIFI -- Toggling WIFI after powerup boot has the same effect as logging off/on.
k
They say if you can't reproduce it, it's not a bug.
Well this is a bug. I was able to reproduce the problem in a Live Boot environment with just a few mouseclicks. Think that rules out a few things like user management, tweaks, updates or installed software, and possibly implicates hardware.
Problem computer is a a Toshiba Satellite C8558D that's 7..8 years old. I was unable to reproduce it on a newer HP machine following the same steps.
Steps to reproduce.
1. Boot from stick
2. Open Task Manager and observe stable low CPU usage.
3. Connect to a wireless Router and observe a few normal usage spikes followed by 50% idle CPU. Notice that this high usage remains stable.
4. Dis-connect the router and observe normal low CPU
5. Re-connect router and observe normal low CPU.
The last two steps can be repeated over and over. This strongly suggests the problem occurs only on the initial wireless connection. The initial connection can be made manually, as in the above scenario, or automatically on power-up boot as was my original issue.
So dunno, that's as far as I can go. It still feels like an ill behaved interrupt service routine. BIOS perhaps? ACPI mangling state transitions? Leave that for the next curious soul. Now I gotta figure out some kindof script to toggle the wireless.
And I leave this post hoping it may help some other wanderer down the path.
Jim
The site below is a couple years old but clear, and will help you understand how the "live" system is different than the installed system in several regards concerning CPU system usage requests. Creating a user during installation of a system optimizes CPU usage according to the software being installed.
Try saving the wifi connection first in Network Manager. Disconnect and reconnect using network manager and the problem is resolved. Not a bug. Earlier live versions would not remain connected (fall off on spikes) until the connection was saved, disconnected and reconnected. An installed system should not have this problem, only live disks, but they are written that way for compatibility. All Ubuntu live disks I've ever used settle down after saving the connection, disconnecting and reconnecting. On installed systems once the connection is saved, disconnected and reconnected, set wifi to always connect, and to be avaialbe to all users. By the time you log in CPU usage for wifi will fall off, and the remaining load will dissipate quiclky after the DE loads.
http://blog.scoutapp.com/articles/2015/0...-cpu-stats
With the Toshiba you may have to disable some onboard Toshiba utilities and/or disable the wifi keyboard funtion key.
Learning Linux is a happy thing.
TC
Thanks TC
That link was interesting reading -- great insight into Linux. I spent the next couple hours in follow-up reading. Yeah, it's fun to learn.
Perhaps I was unclear. My last post was meant to show that there is NO difference between a live boot from USB vs a boot from the installed system -- at least in regards to the problem behaviour.
The triggering event is enabling a wifi connection -- the enabling event is a power-up boot. The problem does not occur after a subsequent soft boot (i.e. sudo reboot).
I've got to believe this problem is isolated to the hardware on my bench. If it were more common, there would be lots of complaints, and there would be far fewer installs. When it pops up, the problem is severe enough to make the system unusable. That is why I call it a bug -- marked high severity but low frequency, use work-around.
Jim