| Pemalite said: Random reads/writes and sequential writes are also always slower than sequential reads. The Playstaton 5 is no exception. I think you are starting to get an idea that it's not as black-and-white as Sony/Microsoft/Non-tech literate people are trying to portray it as... But the reason why SSD writes are slower than reads is down to the fundamental technology itself. An SSD cannot "overwrite" data on the SSD, they need to perform an erase operation before initiating the write and this costs time... Impacting performance. But when you have a fresh SSD and all the cells are empty, it doesn't need to perform that erase first, this will increase performance, but it will still be slower than a read, the reason for that... Is the SSD works on a "page system" so if a page is 2kb, the page is 4kb, so the SSD does it's best job to pair up two 2kb pieces of data to fit onto the 4kb page and will often juggle around data, this can also cost time. The SSD also has it's own database essentially that keeps track of where all that data is being written, after a write has been performed the SSD needs to update that database which also takes time. This is the "dumbed down" version essentially. - The issue itself is dubbed "Write amplification" Allot of engineering goes into SSD's to work around the problem with Ram caches, wear leveling, TRIM, data compression/duplication and more... Heck some SSD's will place some sets of data into groups depending on how often they get read/write. |
Thanks, I learned something new about SSDs :)
My confusion however mostly came from the HDD write speed being significantly faster than its read speed. Is that just the luck of the draw, was it writing at the outer orbit while reading from the inner orbit. HDD afaik have constant angular velocity, thus the outside moves much faster than the inside.
Or does it have to do with caching, HDD says thank you for the data and does more work without holding up the test tool.
Second, why are random reads so much slower on SSD. Seek time should be instant, yet sequential reads are still 3.6 to 50 times faster. It actually writes the smallest chunks faster than it can read them. That looks like managing your data chunks is still as important as before. (And probably why, for example, it still takes KSP a long time to load, tons of little files)
Ah looking up what the Q and T stand for helps a bit, Queue depth (number of requests at once) and Threads used. I guess Q1T1 is stress testing the IO controller mainly, all separate requests which the IO controller can add together to write more efficiently, yet while reading I guess the tool waits for the data before sending the next request.
Anyway not as simple as dump a ton of files in a directory and hope for the best. Optimizing for efficient reading of data will still help.
