Jump to content

Is SSD really this much faster than HDD?


You are about to reply to a thread that has been inactive for 895 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Don't really know where to post this, but just wanted to ask you folks.

I just uninstalled FS from my HDD (had cache on my SSD) and reinstalled it on my SSD. Seems to make a world of difference. At my home I get the same FPS, but much faster going up after login. One of the most laggy SIMs I know of, Slatanic, is still laggy but now quite surviveable. It was not really before.

Is SL just having a good day, or does it make that much of a difference?

I dont have a monster machine. Desktop with MSI GeForce GTX970 4GB GDDR5, an i7 and 16 GB RAM. Plugged in at 70 MBPS :)

Edited by HeathcliffMontague
Spelling
Link to comment
Share on other sites

Funnily enough the big "performance boost" for me was the recent replacement of a monitor I'd gotten second hand (meant to allow me to get my system usable faster) that only offered HDMI, VGA and DVI as the inputs with one (same resolution, larger screen area, curved) that offers Display Port, HDMI and DVI-P.

Now why does that difference in ports matter/why do I bother to mention it at all? With the Display Port, my FPS shot up dramatically in many places.

Link to comment
Share on other sites

Putting the cache on an SSD is a big help with texture loading speed. There's no need to put the viewer or the prefs on an SSD; those are loaded once at startup. With the cache, but nothing else, on an SSD, the hard drive light blinks only occasionally.

Link to comment
Share on other sites

On 5/18/2020 at 11:05 PM, Paul Hexem said:

I don't get any FPS improvements on an SSD, but it definitely helps load times with everything, including SL.

That, exactly, here too.

Thing is, I have been using SSDs exclusively for a long time now.  I haven't worn out a single one.  I have experienced failed controllers but I can assure you those were not Samsung SSD.  The FLASH chips on the SSDs with failed controllers were just fine.  Just the controller chips were defective.

Controller failed: G.SKILL Phoenix Series 2.5" 120GB SATA II MLC Internal Solid State Drive (SSD) FM-25S2S-120GBP1

Controller failed: OCZ Agility 3 2.5" 120GB SATA III MLC Internal Solid State Drive (SSD) AGT3-25SAT3-120G

Controller failed: Mushkin Enhanced Chronos 2.5" 120GB SATA III MLC Internal Solid State Drive (SSD) MKNSSDCR120GB

Controller failed: Mushkin Enhanced Chronos 2.5" 240GB SATA III 7mm Internal Solid State Drive (SSD) MKNSSDCR240GB-7

STILL ROCKING: QUANTITY 3 - SAMSUNG 850 EVO 2.5" 500GB SATA III 32 layer 3D V-NAND Internal Solid State Drive (SSD) MZ-75E500B/AM

STILL ROCKING: Samsung SSD 850 EVO M.2 500GB SATA III 

We use Samsung SSDs on many things at work too, including two surveillance video recorders.  It really takes a hell of a lot of writing to wear out CONTEMPRARY SSDs.  The video recorders were eating HDDs in 6 to 9 months.  SSDs are almost 3 years old now, in the same application.  The device is temperature controlled, as recommended by Samsung.  It's in their documentation.

Link to comment
Share on other sites

SSD will always be significantly faster than HDD.

HDDs have moving parts, so, naturally, they're going to be slower.
SSDs have (at least from my understanding) no moving parts, and, as a direct consequence, are significantly faster.

When in doubt, go for SSDs for the speed/OS/etc... stuff, and HDDS for things like, pictures and storage.

Link to comment
Share on other sites

  • 1 year later...

Ive had pretty much negative experiences with using SSD for both SL installation and its cache, my first SSD was one cheaper 256 GB SATA one but even that it was a huge upgrade to run Windows from it and some games its really helped a lot but with SL. Later after a computer replacement moved on M2 SSD-s one for the system and one bigger one for gaming, but for SL... i still dont see any difference... the viewer starts up a lot faster for sure but the way SL handles the cache SSD literally a no help for me, and at the end ive moved both the viewer and cache back to HHD so at last i can hear when its at last loading something instead of waiting in silence for almost nothing happening :/

So long story short, SSD is really good, but SL's cache system is just so terrible its a waste of space on an SSD.

  • Haha 1
Link to comment
Share on other sites

I only use my HDD for file backups any more. But remember also there are different kinds of SSD - you have SSD that runs on the SATA bus so that will be fairly limited (but still way faster than a HDD on the SATA bus) , PCIe SSD, M.2 SSD, and then there is the SSD on the MVMe SSD - those are the small SSD cards that install directly on the motherboard. I have 2 - 1 Tera SSD .NVMe, then my old 1 tera HDD for archives and another really old 1 tera HDD that runs over a USB for more archive. The price has come way down on SSD now really no reason at all to run any program anymore off the HDD. And when I record video in SL via OBS it goes directly on a partition on one my SSD NVMe cards - and I do all my video editing on that same drive partition then I move the completed projects to my HDD for archiving

NVMe SSD:

ssd512g_001_front_black-100631041-orig.j

Link to comment
Share on other sites

If you have a sufficient amount of RAM (16GB and preferably more), your best bet is to use a RAM-disk for the viewer cache: it is the fastest, by several orders of magnitude, and will prevent to wear out SSDs and HDs.

A 2GB RAM-disk is enough, at least for one viewer (be aware that different viewers normally use different cache directories, so their cache size would add up in your RAM-disk).

Edited by Henri Beauchamp
  • Like 2
Link to comment
Share on other sites

2 hours ago, Henri Beauchamp said:

RAM-disk for the viewer cache: it is the fastest, by several orders of magnitude, and will prevent to wear out SSDs and HDs.

I'm interested to know just how much an SSD is likely to have it's operating life shortened by being used for the cache: once you've visited all your normal spots, there's not going to be a lot of writing to the cache, mostly it's going to be reads?

I admit my views are based on what is effectively black-box testing, and there is one area where I might just be wrong about the cache being used for reads: after some TP-crashes there is such a turmoil reloading the scene that I have a suspicion the crash resulted in the cache being marked as faulty and every texture is being fetched again.

I'm currently switching my cache folders as well as some train-simulators to an SSD: both SL and the simulators do a lot of disk reads but comparatively little disk writes. I can do this getting quite small SSDs, perhaps 250G, so replacing them won't be too much of a hit, but if I am wrong about the majority of access being reads I would like to know.

My understanding is that disk writes to an SSD are heavy in that they require an entire strip of adjacent cells to be written rather than one single component of them, and it is this strip-re-writing that ultimately causes the SSD failure?

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

15 minutes ago, Profaitchikenz Haiku said:

I'm interested to know just how much an SSD is likely to have it's operating life shortened by being used for the cache: once you've visited all your normal spots, there's not going to be a lot of writing to the cache, mostly it's going to be reads?

I admit my views are based on what is effectively black-box testing, and there is one area where I might just be wrong about the cache being used for reads: after some TP-crashes there is such a turmoil reloading the scene that I have a suspicion the crash resulted in the cache being marked as faulty and every texture is being fetched again.

I'm currently switching my cache folders as well as some train-simulators to an SSD: both SL and the simulators do a lot of disk reads but comparatively little disk writes. I can do this getting quite small SSDs, perhaps 250G, so replacing them won't be too much of a hit, but if I am wrong about the majority of access being reads I would like to know.

My understanding is that disk writes to an SSD are heavy in that they require an entire strip of adjacent cells to be written rather than one single component of them, and it is this strip-re-writing that ultimately causes the SSD failure?

From my experience you would go a lot better to use a decent HDD (still a lot cheaper than an SSD) for the SL Cache because SL's cache system is a literal garbage, its writing way too much than needed, and seriously the most trashy cache system ive ever seen... and i really mean that, everyting SL for me literally loads way faster if i login with a completly empty cache than with a cache that supposed to contain everything i need to see... this is pretty much the reason why ive said using SSD for SL cache is just a waste of space.

Link to comment
Share on other sites

I wonder if setting up a ramdisk would be a decent option, it would be erased every time you restart your computer though.  Honestly though, I rarely have to restart my computer now.  I have more than enough ram to setup a 5gb disk, which should be sufficient.   It would be fast, and wouldn't wear out my SSD which would be nice.

Link to comment
Share on other sites

11 minutes ago, Istelathis said:

it would be erased every time you restart your computer though

I did try this option back in 2010, I copied the cache to the ram disk at startup, and back to disk after logging out. It worked well enough back in 2010 when 512M was sufficient for the cache, but doing it now with 1-2G would be tedious.

 

1 hour ago, Venompapa said:

nd i really mean that, everyting SL for me literally loads way faster if i login with a completly empty cache than with a cache that supposed to contain everything i need to see..

I have also noticed this but I think it is showing up the time it takes to locate and fetch a specific file in a mass of others on a spinning platter, with the network download this searching time is eliminated.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Profaitchikenz Haiku said:

I'm interested to know just how much an SSD is likely to have it's operating life shortened by being used for the cache: once you've visited all your normal spots, there's not going to be a lot of writing to the cache, mostly it's going to be reads?

Even for reads, the cached files need to have their last access time updated, so that the cache code knows what files to evict first when it needs to make room for new files (it of course first evicts the files that have not been accessed in the longest time).

On HDs, this is not an issue, but on SSDs, where writes are done at a block granularity (i.e. you cannot just write a couple of bytes in the Flash memory: you must erase and rewrite an entire block with the few updated bytes), it can cause an excessive wear. While MLC and multi-layer TLC Flash is usually endurant enough, I won't use any single-layer TLC or multi-layer QLC for a cache (not to mention TLC and QLC writes are slow and/or cause an excessive ”write amplification”, due to the fact that each block is first written in an area used as a pseudo SLC flash, for speed, and rewritten later in the TLC/QLC ”standard” area) !

44 minutes ago, KT Kingsley said:

The LL RC viewer, Simplified Cache is available here: https://releasenotes.secondlife.com/viewer/6.4.23.562623.html. I've no idea how, or if, it improves on the existing system.

It is just simpler (and faster, at least under Linux and macOS; Windows is another story, especially just after a reboot, when the OS does not yet have a cached directory tree in RAM). It however does not solve SSD wearing (even though it attempts to mitigate it by not writing the access time at every read if the last read timestamp is recent enough).

38 minutes ago, Istelathis said:

I wonder if setting up a ramdisk would be a decent option, it would be erased every time you restart your computer though.

A proper RAM-disk saves its contents on disk on OS shut down and restores it on reboot...

23 minutes ago, Profaitchikenz Haiku said:

I did try this option back in 2010, I copied the cache to the ram disk at startup, and back to disk after logging out. It worked well enough back in 2010 when 512M was sufficient for the cache, but doing it now with 1-2G would be tedious.

Not at all. Here (under Linux), it takes just a couple of seconds to save a 2GB RAM-disk and even less to restore it: I do not even bother compressing the RAM-disk data (which would take more time): I just 'tar' it to the SSD and voilà.

Edited by Henri Beauchamp
  • Thanks 1
Link to comment
Share on other sites

9 minutes ago, Henri Beauchamp said:

A proper RAM-disk saves its contents on disk on OS shut down and restores it on reboot...

I've just created one on Windows 10 and it is much faster than from my HDD.  I am currently using 4gb, but I think I'll try to bring it down to 2gb to see how well it works.  Now I just need to find a way to ensure that it saves my contents to my HDD rather than SSD on shutdown :) Thank you.

Link to comment
Share on other sites

5 minutes ago, Henri Beauchamp said:

Even for reads, the cached files need to have their last access time updated, so that the cache code knows what files to evict first when it needs to make room for new files. On HDs, this is not an issue, but on SSDs, where writes are done at a block granularity (i.e. you cannot just write a couple of bytes in the Flash memory: you must erase and rewrite an entire block with the few updated bytes),

OK, surely though it's the directory block(s) that have such information rather than the areas containing the file data and they're going to be frequently updated this way anyway?

 

8 minutes ago, Henri Beauchamp said:

Not at all. Here (under Linux), it takes just a couple of seconds to save a 2GB RAM-disk and even less to restore it: I do not even bother compressing the RAM-disk data (which would take more time): I just 'tar' it to the SSD and voilà.

Would there be any benefit to splitting up the cache so that the textures (and other fast-frequent access files such as animations) could be stored in Ram disk rather than the whle cache?

Link to comment
Share on other sites

25 minutes ago, Profaitchikenz Haiku said:

OK, surely though it's the directory block(s) that have such information rather than the areas containing the file data and they're going to be frequently updated this way anyway?

Under Linux for an ext4 file system, you use the ”noatime” option (at the minimum; I use personally lazytime,noatime,nobarrier,delalloc,discard) to prevent ”last accessed” time stamp update, when using a SSD. So the cache defeats that mechanism...

Not to mention this is not even the ”last access time” data which is updated on reads in the ”simple cache”, but the ”last write time” (because you need to make sure this time stamp is indeed the result of a cache code access, and not of some random read from the file explorer, wsearch daemon or whatnot). Even with the old VFS-based cache (a single large cache file holding a virtual file system), that ”last used” info had to be stored as bytes inside the VFS file...

Quote

Would there be any benefit to splitting up the cache so that the textures (and other fast-frequent access files such as animations) could be stored in Ram disk rather than the whle cache?

There are several separate caches in use by the viewer:

  • The textures cache.
  • The assets cache (animations are among them, but meshes are by far the largest stored assets in it) or VFS.
  • The objects cache (per-sim files).
  • The inventory list cache.
  • Some other minor cache files (names cache, mute list, decoded sound files, etc).

You could eventually separate the textures, assets and objects caches from the rest, but I do not really see any benefit in doing it...

Edited by Henri Beauchamp
Link to comment
Share on other sites

I am really impressed with the ramdisk so far,  I brought my cache down to 2.5gb and created the backup on my SSD as it was much faster of a process.  At around 2gb, it does have a noticeable impact on my restart time, for me it is almost 2 minutes from shutdown to rebooting to the login screen on windows 10.  I'm okay with that, since I reboot infrequently.  The change is worth it, as my fps has risen dramatically.  Where as I used to have my draw distance set to 64 and I had constant lag, I now have it to 128 meters and it runs much smoother with hardly any lag.  

With 4gb of ramdisk, and about 3gb used, with a back up on my HDD it took nearly six minutes to do an entire reboot.. that was a bit too much for my taste, thus I switched over to SSD and brought down the size of my cache.

I think I might just disable the ramdisk from saving my cache to the SSD entirely as it really is not necessary.  My internet speed is fast enough that it doesn't take long to fill it back up.  

Edited by Istelathis
Link to comment
Share on other sites

30 minutes ago, Istelathis said:

At around 2gb, it does have a noticeable impact on my restart time, for me it is almost 2 minutes from shutdown to rebooting to the login screen on windows 10.  I'm okay with that, since I reboot infrequently. 

.../...

With 4gb of ramdisk, and about 3gb used, with a back up on my HDD it took nearly six minutes to do an entire reboot.. that was a bit too much for my taste, thus I switched over to SSD and brought down the size of my cache.

This sounds way too long to me... A few seconds should suffice to backup 4 GB or data to your SSD...And yes, a 2GB cache would be plenty enough to store the data for at least 4 of your preferred/most visited places: increasing the size is hardly bringing any benefit (if you travel a lot in main land, the cached files will get evicted from the cache at some point anyway, whatever its size).

I do not know what RAM-disk software (or script) you are using, but it looks like (by the time it takes) it uses compression: just disable the latter and store the data uncompressed, and if possible, as a single file (as a 'tar' file under Linux or an equivalent for other OSes: zip can do it with the ”do not compress” '-0' option, for example).

Quote

I think I might just disable the ramdisk from saving my cache to the SSD entirely as it really is not necessary.  My internet speed is fast enough that it doesn't take long to fill it back up. 

Things such as the inventory list cache takes time to load, even with a fast Internet link, and without a loaded inventory, your avatar will stay a cloud: you might want to at least save and restore the inventory cache files...

Edited by Henri Beauchamp
  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
14 hours ago, Coffee Pancake said:

You can buy a cheap Inland 120GB SSD for $20, see your local microcenter or Amazon.

I won't use a cheap SSD for caching purposes (and truth to be told and as far as I am concerned, for no purpose at all): they are especially fragile with a low endurance (low max write cycle counts), while a cache disk needs high endurance to writes. They are also slow (you will find QLC or non-V-NAND TLC drives in this ”cheap” category, and their write speed is abyssal).

I'd rather use a RAM-disk, and if RAM is scarce on my system (less than 16GB), I'd rather consider adding more RAM (you can find 8GB DDR4 modules around 30-50 bucks, and you can even buy second-hand modules for RAM, while buying second-hand SSDs is quite unwise) so to be able to create a RAM-disk; the added RAM will also benefit all applications more than your cheap SSD would, the SL viewer included.

Link to comment
Share on other sites

4 hours ago, Henri Beauchamp said:

I won't use a cheap SSD for caching purposes (and truth to be told and as far as I am concerned, for no purpose at all): they are especially fragile with a low endurance (low max write cycle counts), while a cache disk needs high endurance to writes. They are also slow (you will find QLC or non-V-NAND TLC drives in this ”cheap” category, and their write speed is abyssal).

I've hammered the fire out of a few cheap SSD's and been very surprised by their actual performance and longevity, of course they aren't a patch on more expensive drives, but they are worlds better than a spinning platter and despite my best efforts, I've not managed to kill one yet (although I have managed to kill quite a few HDDs).

A $20 quick scratch drive is a no-brainer, especially when it can be used as a dumping ground for IO intensive junk that saves wear on the better more expensive drives.

4 hours ago, Henri Beauchamp said:

I'd rather use a RAM-disk, and if RAM is scarce on my system (less than 16GB), I'd rather consider adding more RAM (you can find 8GB DDR4 modules around 30-50 bucks, and you can even buy second-hand modules for RAM, while buying second-hand SSDs is quite unwise) so to be able to create a RAM-disk; the added RAM will also benefit all applications more than your cheap SSD would, the SL viewer included.

Buying second hand ram is a minefield, there is a lot of bad ram kicking about and the fix is to hawk it on eBay and make it someone else's problem.

I have a lot of computers, ranging from new high end to vintage junk. eBay ram is the bane of my hobby.

You also have to factor in typical SL hardware, it's mostly mid range & business laptops running well beyond their capabilities and service life. 

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 895 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...