The Impact Of HDD/SSD Performance On Linux Gaming

[glasen]

If there's a fault, you simply need to take a look at the data. It's hard to guess what's wrong.

It's very easy to guess whats wrong with the numbers:

Here are the numbers of the first boot of my PC today:

Startup finished in 6.401s (firmware) + 132ms (loader) + 2.750s (kernel) + 15.265s (userspace) = 24.549s

        10.894s apt-daily.service
          3.214s apt-daily-upgrade.service
           274ms tpdaemon.service
           250ms tlp.service
           245ms systemd-fsck@dev-disk-by\x2duuid-d6596b40\x2d7013\x2d4f63\x2db4fb\x2d15aed03c3ce0.service
           191ms dev-sda2.device
           165ms data.mount
           141ms libvirtd.service
           128ms systemd-resolved.service
           111ms systemd-timesyncd.service
           105ms gpu-manager.service
            97ms upower.service
            68ms accounts-daemon.service
            68ms keyboard-setup.service [..]

Boot time stop watch (Pushing Power button up to GDM is ready): ~14s - 6.4s = ~8s

https://www.dropbox.com/s/fvc3cbszgu...first.svg?dl=0

Next are the boot times after restarting the system:

Startup finished in 6.400s (firmware) + 132ms (loader) + 2.777s (kernel) + 1.698s (userspace) = 11.009s

          277ms tlp.service
           268ms tpdaemon.service
           223ms systemd-fsck@dev-disk-by\x2duuid-d6596b40\x2d7013\x2d4f63\x2db4fb\x2d15aed03c3ce0.service
           197ms dev-sda2.device
           190ms systemd-resolved.service
           156ms systemd-localed.service
           144ms systemd-hostnamed.service
           143ms data.mount
           117ms libvirtd.service
           117ms systemd-timesyncd.service
            92ms upower.service
            92ms gpu-manager.service
            73ms keyboard-setup.service
            67ms NetworkManager.service
            66ms udisks2.service
            48ms systemd-udev-trigger.service
            46ms packagekit.service

Boot time stop watch (Pushing Power button up to GDM is ready): ~14s - 6.4s = ~8s

https://www.dropbox.com/s/wloprlm4s3...econd.svg?dl=0

As you can see "apt-daily.service" and "apt-daily-upgrade-service" add ~14s to the total boot time "measurement" of "systemd-analyze" even when both have absolutely no impact on the actual stop watch measured boot time. And the latter is the time the user will notice because at this point the system is ready to use.

[caligula]

I have a stopwatch. The stopwatch says 8s for booting the system to GDM and another 3s to GNOME-Shell. If the "systemd-analyze" says it took 30s then the latter is wrong or misleading.

If there's a fault, you simply need to take a look at the data. It's hard to guess what's wrong. The default output of systemd-analyze shows when graphical.target is up, that is the old runlevel 5. By default it's nothing more than runlevel 3 + GDM in your case. Maybe it shows the time spent on some other service that GDM does not depend on (even recursively). FWIW, those services should not take that long. It's easy to spot what's wrong from the graph. Or from any of the other commands listed here..

[glasen]

Take a look at your data, stop guessing.

I have a stopwatch. The stopwatch says 8s for booting the system to GDM and another 3s to GNOME-Shell. If the "systemd-analyze" says it took 30s then the latter is wrong or misleading.

[xpander]

If you have memory its not much of an issue. I have run games from USB external drives fine. Initial load times are bad but if your playing say Skyrim. After a few loading screens all the assets are in ram cached and running faster than an storage could do. Add to that games barely challenge drive speed to start with. Let take Civ V the most CPU and disk usage is loading a saved game it hits 400% on CPU and double digit MB/sec and thats it. Calulatiing turns is barely hitting 200% on a ryzen 1700 that has if use use top logic 1600% of capacity like what blender would user. Games are just code crap.

Unreal Engine games are specially known for having really big framerate drops when running on HDD vs SSD: ARK: Survival Evolved, Observer, Borderlands 2, Saints Row the Third (eON wrapper); Rust (Unity) just to name few.

Those i think sadly don't have benchmark modes. Can't remember others atm from the top of my head which have benchmark mode also. but basically all the games he tested shouldnt suffer from this indeed.. Bioshock Infinite i think did have more drops on HDD also than on SSD

[rukur]

If you have memory its not much of an issue. I have run games from USB external drives fine. Initial load times are bad but if your playing say Skyrim. After a few loading screens all the assets are in ram cached and running faster than an storage could do. Add to that games barely challenge drive speed to start with. Let take Civ V the most CPU and disk usage is loading a saved game it hits 400% on CPU and double digit MB/sec and thats it. Calulatiing turns is barely hitting 200% on a ryzen 1700 that has if use use top logic 1600% of capacity like what blender would user. Games are just code crap.

[xpander]

what about framerates on different drives? specially games where it loads new textures etc onfly or reading shader cache or similar

[eydee]

Can't see Valve Source games in the list, even though those are the most notorious about having load-time issues on linux.

[caligula]

No, it doesn't. My system always boots in 8s to GDM even when "apt-daily" is running and "systemd-analyze" says that the system took 30s to boot. And Michael seems to have used just the output of "systemd-analyze" and not "plot" or "critical-chain" to get the number.

Take a look at your data, stop guessing.

[glasen]

It just shows when graphical.target is up. If you take a look at the plot or critical-chain output, you'd see this. It really depends on which login manager and other services you're using, how you launch them, and so forth.

No, it doesn't. My system always boots in 8s to GDM even when "apt-daily" is running and "systemd-analyze" says that the system took 30s to boot. And Michael seems to have used just the output of "systemd-analyze" and not "plot" or "critical-chain" to get the number.

[caligula]

I already know that the time measured be "systemd-analyze" is not the true time the system is ready to use.

It just shows when graphical.target is up. If you take a look at the plot or critical-chain output, you'd see this. It really depends on which login manager and other services you're using, how you launch them, and so forth.