On 11/17/17 10:08, Temlakos wrote:

On 11/16/2017 06:18 PM, Ed Greshko wrote:

...

On 11/17/17 05:09, Temlakos wrote:

...

This morning I took the upgrade--all 100-odd parts of it. And ever since then, I cannot afford to leave my system on for more than an hour--two hours at the outside--without having it get progressively slower and then hang up. I've had to force-shutdown my system and restart it to get anything done. I've tried reverting to the "last known good kernel." No joy. The desktop is now at fault.

I wouldn't know where to begin for filing a bug--what do I file the bug against? All I know is--it's going to take another K desktop upgrade to fix this. Until then, I'm running my system only intermittently.

My oldest system is an "Intel(R) Core(TM)2 Duo CPU 1.66GHz".  It was running F26 with an HDD consistently slow.  I replaced the HDD with a SDD and performance improved markedly.  I have since upgraded to F27 and have no issues.  The system is up 24/7.

I suppose you need to start by using "top" or a similar utility to see what process may be taking up resources.

Well, first that doesn't explain why the system went flaky with the last KDE update and was doing just fine before.

I was not talking about your problem when I was describing my system.  I was just pointing out that it is an old and under powered compared to current systems.  And, it is not having any problems after upgrade to F27 and being fully updated.

Also--and this might strike you as somewhat old-fashioned an outlook--no one has ever explained to me why SDD's are non-volatile. Are they volatile or non-volatile? Or am I missing something? And what is the maximum capacity of an SDD, and how exactly do I manage to replace it?

Your questions as to the SDD technology is not relevant to this discussion.  But my drive happens to be 275GB, has a SATA interface.  So, unplug the HDD and plug-in the SDD.

But, again, you need to look at your system with "top" or any utility that shows what processes are consuming resources and slowing things down.  Without that information you'll won't have much of a chance.

Just to answer the OP's question on SSD's.

Yes, they are non volatile and older spinning HDD's can be replaced with them assuming your system has at least a SATA disk interface. There are different types. They do have limited data retention times though, earlier versions could start to lose data after about 4 months if left un-powered. The latest generation is better (> year ?) but figures are hard to come by and depend heavily on temperature. For normal use this is not a problem. There are much faster especially when accessing multiple small files as there effective random seek time is very very fast compared with a mechanical HDD.

Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot times due to disk access requirements. With a spinning HDD system boot times are really bad (minutes). A SSD helps this but obviously the issue is really in KDE5/Plasma. With this aspect improved systems would be so much faster better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology is to blame reading loads of small files describing GUI interface parts rather than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type machine takes much longer to boot than an old 400 MHz single core Pentium Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora with KDE3. The price of bad software "progress".

On 17/11/17 16:11, Kevin Kofler wrote:

Terry Barnaby wrote:

...

Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot times due to disk access requirements. With a spinning HDD system boot times are really bad (minutes). A SSD helps this but obviously the issue is really in KDE5/Plasma. With this aspect improved systems would be so much faster better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology is to blame reading loads of small files describing GUI interface parts rather than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type machine takes much longer to boot than an old 400 MHz single core Pentium Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora with KDE3. The price of bad software "progress".

I agree wholeheartedly, this is really sad.

I have been complaining about everincreasing bloat and abuse of slow interpreted languages (such as Q-M-Hell) for years now, but it looks like the developers just don't care. :-(

     Kevin Kofler

Also just think of the wasted electrical energy all of this bad software design/implementation is using when multiplied by the number of systems out there, not just KDE5/Plasma. Software developers need to be considering this much more these days. About time for a trash of all the now complex development approaches/languages/systems back to square one with new simpler languages/development methods/OS's me thinks :)

On Fri, 2017-11-17 at 15:45 +0000, Terry Barnaby wrote:

Just to answer the OP's question on SSD's.

Yes, they are non volatile and older spinning HDD's can be replaced with them assuming your system has at least a SATA disk interface. There are different types. They do have limited data retention times though, earlier versions could start to lose data after about 4 months if left un-powered. The latest generation is better (> year ?) but figures are hard to come by and depend heavily on temperature. For normal use this is not a problem. There are much faster especially when accessing multiple small files as there effective random seek time is very very fast compared with a mechanical HDD.

Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot times due to disk access requirements. With a spinning HDD system boot times are really bad (minutes). A SSD helps this but obviously the issue is really in KDE5/Plasma. With this aspect improved systems would be so much faster better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology is to blame reading loads of small files describing GUI interface parts rather than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type machine takes much longer to boot than an old 400 MHz single core Pentium Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora with KDE3. The price of bad software "progress".

I installed a 120GB Samsung SSD for / about 3 years ago. My i7-3770 (also 3 years old and the 3770 is not the fastest i7) takes 12 seconds from boot menu to login screen, and under 20 from login to KDE (autostarting 6 virtual desktops, a couple of Konsoles, a Qbittorrent instance and Evolution, but no browser). Even a small SSD is a worthwhile investment.

poc

On Saturday, 18 November 2017 3:41:14 AM AEDT Reindl Harald wrote:

Am 17.11.2017 um 17:34 schrieb Patrick O'Callaghan:

...

I installed a 120GB Samsung SSD for / about 3 years ago. My i7-3770 (also 3 years old and the 3770 is not the fastest i7) takes 12 seconds from boot menu to login screen

not very impressing, that below is a 6 years old 4-drive-RAID10 with 6 years old rotating disks - i expect a proper configured system with useless services disabled to boot on a SSD far below 10 seconds

Startup finished in 998ms (kernel) + 1.059s (initrd) + 16.948s (userspace) = 19.006s

That's not bad....

Startup finished in 19.474s (firmware) + 1.227s (loader) + 4.935s (kernel) + 2.036s (initrd) + 5.140s (userspace) = 32.814s

Thats with a Ryzen 1700x, 16Gb RAM and an NVMe PCIe SSD...

There is a 2 second wait at the GRUB menu for my dual boot, but otherwise, how'd you get things so quick? o_O

Am 17.11.2017 um 18:23 schrieb Reindl Harald:

Am 17.11.2017 um 17:57 schrieb Steven Haigh:

...

how'd you get things so quick?

the grub timeout is not part of that game!

by just add 4 fast HDD's to a RAID10 and remove/disable everything which i don't really need, in a RAID10 reads canm be done from all 4 drives - large files are striped on two disks and each of the stripes has a mirror, so the OS can read 25% of the file parallel from a different drive

"systemd-analyze blame" is one of your friends in that context

On 17/11/17 19:35, Luigi Toscano wrote:

Terry Barnaby ha scritto:

...

Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot times due to disk access requirements. With a spinning HDD system boot times are really bad (minutes). A SSD helps this but obviously the issue is really in KDE5/Plasma. With this aspect improved systems would be so much faster better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology is to blame reading loads of small files describing GUI interface parts rather than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type machine takes much longer to boot than an old 400 MHz single core Pentium Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora with KDE3. The price of bad software "progress".

I think that a blank statement like "QtQuick produces the slow startup" should be backed by some statement, not just by "I think".

For example, I remember some time ago a set of patches in few libraries part of Frameworks to improve the lookup of the icons, which was hitting the startup of same applications, and it was not related to QtQuick or QtWidgets. This is to underline the fact that "tons of small files" may not be the problem, especially because they can be put together in a resource file.

I didn't say "QtQuick produces the slow startup",  I said "I suspect ..." :)

A statement like "QtQuick produces the slow startup" should indeed be backed up by some evidence,  that would take a bit of work to concisely determine what is happening and would have to be performed by those who know some of the details of the architecture of the KDE5/Plasma system.

It is a fact that KDE5/Plasma is slow to boot/start up on a spinning HDD. There are some figures I and others have posted a while back in this list and lots of people recommend using an SSD when using KDE5/Plasma. As the boot/startup speed difference between a spinning HDD and SSD is so dramatic, this points to lots of small file accesses (seek times are the main culprit of slow HDD access).

I just did some quick and simple tests by using "strace -f -tt -e trace=open,execve -o /tmp/strace_startkde.txt /usr/bin/startkde1" in a shell script place of /usr/bin/startkde (/usr/bin/startkde moved to /usr/bin/startkde1).

With my Fedora25 KDE/Plasma login (Dual monitor and has a manual session setup with Thunderbird, Firefox, Dolphin and 8 konsoles, NFS /home/... ) there are 62122 file opens. (A virgin system default KDE5/Plasma boot/startup still takes a relatively long time). This does include shared libraries /dev, /sys accesses etc. and so a lot of these can perhaps not be really considered as a real file access.

Ignoring /lib64/*, /dev/*, /sys/* and /run/* accesses there are 17276 file opens. The boot/start up takes 52 seconds on a i5-3450 CPU @ 3.10GHz system with a fast SSD with the strace running.

As far as QtQuick, assuming these are the just "*.qm"  and "*.qml" files only there are 1194 file accesses so maybe it isn't the QtQuick side that is the main issue but we would have to time each file read access to really see where the time is being used.

This needs more work, but 62122 file opens just to login to a KDE5/Plasma session seems a bit high !

Terry

On 11/18/2017 12:56 PM, Robin Laing wrote:

On 18/11/17 03:44, Terry Barnaby wrote:

...

On 17/11/17 19:35, Luigi Toscano wrote:

...

Terry Barnaby ha scritto:

...

...

For example, I remember some time ago a set of patches in few libraries part of Frameworks to improve the lookup of the icons, which was hitting the startup of same applications, and it was not related to QtQuick or QtWidgets. This is to underline the fact that "tons of small files" may not be the problem, especially because they can be put together in a resource file.

I didn't say "QtQuick produces the slow startup",  I said "I suspect ..." :)

A statement like "QtQuick produces the slow startup" should indeed be backed up by some evidence,  that would take a bit of work to concisely determine what is happening and would have to be performed by those who know some of the details of the architecture of the KDE5/Plasma system.

It is a fact that KDE5/Plasma is slow to boot/start up on a spinning HDD. There are some figures I and others have posted a while back in this list and lots of people recommend using an SSD when using KDE5/Plasma. As the boot/startup speed difference between a spinning HDD and SSD is so dramatic, this points to lots of small file accesses (seek times are the main culprit of slow HDD access).

I just did some quick and simple tests by using "strace -f -tt -e trace=open,execve -o /tmp/strace_startkde.txt /usr/bin/startkde1" in a shell script place of /usr/bin/startkde (/usr/bin/startkde moved to /usr/bin/startkde1).

With my Fedora25 KDE/Plasma login (Dual monitor and has a manual session setup with Thunderbird, Firefox, Dolphin and 8 konsoles, NFS /home/... ) there are 62122 file opens. (A virgin system default KDE5/Plasma boot/startup still takes a relatively long time). This does include shared libraries /dev, /sys accesses etc. and so a lot of these can perhaps not be really considered as a real file access.

Ignoring /lib64/*, /dev/*, /sys/* and /run/* accesses there are 17276 file opens. The boot/start up takes 52 seconds on a i5-3450 CPU @ 3.10GHz system with a fast SSD with the strace running.

As far as QtQuick, assuming these are the just "*.qm"  and "*.qml" files only there are 1194 file accesses so maybe it isn't the QtQuick side that is the main issue but we would have to time each file read access to really see where the time is being used.

This needs more work, but 62122 file opens just to login to a KDE5/Plasma session seems a bit high !

Terry

I for one won't be getting an SSD for me for some time until the price drops to a reasonable range and disk size so that isn't an option.

I do like what you wrote about the strace.  It would be interesting to see what is being done to slow the login process.

I find the boot to sddm is slow enough but isn't done that often so I don't find it as an issue.  The time it takes to login is the big issue.

I would like to try this on F26 and maybe F27 to see if there are many differences.

The list of 62122 file opens is a major issue for just a login. There is really something that needs to be looked at.

If the KDE development keeps in this direction, it wont' be winning many fans.  I know of one person that has moved away due to the resources being used on their laptop.

Robin

Well, Robin, I'll tell you what. I /did/ kick over the traces and bought a 1-TB SSD for SATA buses. I shudder to think of the price I paid. But I was desperate to avoid having to shut down and restart (or may I simply log out and log back in) four or five times a day.

And I have another problem. When I run my system too long, the HDD starts to buzz. In fact, I hear the buzzing sometimes when I start up. Surely that's a sign of the HDD's age, and that if I go on long enough, it will fail.

So here's my plan. When my HP SmartBuy 1TB SSD arrives, and someone comes in to move my data and partitions and so on to it, then put it in, I'll be back here with a review.

Temlakos

PS: has the time come to make those disks insertable, as I once saw done when I took the Microsoft System Engineering class in Windows NT?

Temlakos

On 18 November 2017 at 20:22, Temlakos temlakos@gmail.com wrote:

Well, Robin, I'll tell you what. I did kick over the traces and bought a 1-TB SSD for SATA buses. I shudder to think of the price I paid.

I can't think why you would need a 1TB SSD. I recommend a small (say 100GB or so) SSD for the root filesystem and keeping the rest, including home directories, on a rotating drive. The price for large SSDs is still much greater than for rotating rust, and you're getting very little additional benefit from it. As I said earlier my SSD is 120GB, current price about £50 (it cost more when I got it). My /home is on a 2TB drive I bought recently for £55. A 1TB SSD (i.e. half the size) currently costs around 6-7 times as much.

poc

On 11/17/2017 10:45 AM, Terry Barnaby wrote:

Just to answer the OP's question on SSD's.

Yes, they are non volatile and older spinning HDD's can be replaced with them assuming your system has at least a SATA disk interface. There are different types. They do have limited data retention times though, earlier versions could start to lose data after about 4 months if left un-powered. The latest generation is better (> year ?) but figures are hard to come by and depend heavily on temperature. For normal use this is not a problem. There are much faster especially when accessing multiple small files as there effective random seek time is very very fast compared with a mechanical HDD.

Yes, the latest KDE5/Plasma is horrendously inefficient when it comes boot times due to disk access requirements. With a spinning HDD system boot times are really bad (minutes). A SSD helps this but obviously the issue is really in KDE5/Plasma. With this aspect improved systems would be so much faster better even with SSD's. I suspect the use of the QtQuick (QtSlow!) technology is to blame reading loads of small files describing GUI interface parts rather than just using C++. With a standard fast HDD, a 3 GHz quad core i5 type machine takes much longer to boot than an old 400 MHz single core Pentium Laptop with 256 MBytes of RAM and an slow 2.5inch HDD running an old Fedora with KDE3. The price of bad software "progress". _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org

The latest upgrade from F26 to F27 might have solved the problem. The problem was never booting (though that does take a long time), but a gradual slowdown in the course of my work. That's why I have to keep shutting down and rebooting. The upgrade seems to have made things stay faster longer.

Nevertheless I am going to accept the suggestion of Ed Greshko and others. I have ordered an HP SmartBuy 1-TB SSD with a SATA bus to match the bus in my present system. (That system is also an HP, FWIW.) I have also booked an appointment with a professional to see to its installation and the data migration. Frankly I've been worrying about the HDD for some time--it makes an awful lot of noise sometimes, and a noisy HDD is one wearing itself out, IIRC. Sure I'm paying a bundle for the new drive--but I did not wish to sacrifice capacity. I'm also reasonably sure I would /not/ be leaving the computer powered down for four months at a time. A week, maybe. Two weeks at the outside. I gather I shouldn't lose data during such an interval.

Temlakos