Announcement

Collapse
No announcement yet.

The Impact Of HDD/SSD Performance On Linux Gaming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by glasen View Post
    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.

    Comment


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

      Comment


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

        Comment


        • #24
          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.

          Comment


          • #25
            Originally posted by rukur View Post
            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

            Comment


            • #26
              Originally posted by caligula View Post

              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.

              Comment


              • #27
                Originally posted by glasen View Post
                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..

                Comment


                • #28
                  Originally posted by caligula View Post
                  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:

                  Code:
                  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 [email protected]\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:

                  Code:
                  Startup finished in 6.400s (firmware) + 132ms (loader) + 2.777s (kernel) + 1.698s (userspace) = 11.009s
                  
                            277ms tlp.service
                             268ms tpdaemon.service
                             223ms [email protected]\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.

                  Comment

                  Working...
                  X