Announcement

Collapse
No announcement yet.

The Impact Of HDD/SSD Performance On Linux Gaming

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

  • glasen
    replied
    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.

    Leave a comment:


  • caligula
    replied
    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..

    Leave a comment:


  • glasen
    replied
    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.

    Leave a comment:


  • xpander
    replied
    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

    Leave a comment:


  • rukur
    replied
    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.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • caligula
    replied
    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.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X