My Su800 is getting much lower 4k64 thread speed than it should

>>321327
Member that performance is dependent on number of dies which is dependent on capacity. Be sure you're comparing with other drives of the same capacity.

>>321327
IDE mode doesn't support NCQ or TRIM, so your SSD will never have been trimmed, and windows' storage subsystem might not even know to optimise for an SSD (because without NCQ you can only have one IO in flight at once, which kneecaps the SSD).

So you probably need to:

Run "winsat formal" to rebenchmark the SSD so Windows can optimise it as an SSD not a hard disk

TRIM your free space. There's a tool that you can find by googling trim-for-masses_10.html (thanks spamfilter) that should work, though I haven't personally tried it.

Defragment your filesystem. This will make the requests going into the FTL less tangly, meaning the individual FTL mappings can map more space, so more space can be cached, plus each file is likely to be spread across fewer erase blocks.

>>321331
I am.

>>321338
Gonna try this, brb

File: assd.png (34KB, 504x507px) Image search: [Google]

34KB, 504x507px

>>321338
Getting the same results.
http://www.userbenchmark.com/UserRun/3799589
Still can't comprehend how so many ppl are getting 150 mb/s+ DQ speed. Might just be userbenchmark being crap on my particular system? Because I got very different results across the board with this program.

>>321375
How many threads does your processor support, does your SATA controller do SATA III, and how does it connect to your CPU and your RAM?

>>321389
the cpu has 4 threads if that's what you're asking.
yes it's on Sata III, IDK how it communicates with the CPU, presumably through the southbridge?
Pretty sure it doesn't communicate with the RAM directly at all because it's not the CPU it's an i/o controller.

>>321411
All devices have been able to communicate with RAM directly, since the ISA bus. It's crucial to decent performance: the CPU says "I need this sector read into this address", and the disk controller sends the command to the drive, waits for the result, then when the device sends it the controller locks the region of RAM and writes the sector directly into it.

This used to be called "DMA" but is now called "bus mastering"; there are technical differences* but it's essentially the same thing.


* the main difference is that with DMA the device writes to memory directly, whereas with bus mastering the device uses a mezzanine bus (such as PCI or PCIe) to communicate with the memory controller. Because the device itself is initiating the transaction, it's said to become the "bus master", and while it's doing so the CPU isn't in charge of the bus and has to wait its turn.

File: image.jpg (60KB, 1026x323px) Image search: [Google]

60KB, 1026x323px

>>321417
>>321411
The tl;dr on this is that SATA III needs more bandwidth than a single PCIe 2.0 lane can supply, so if your controller is on a PCIe card (as opposed to, say, built into the PCH), then your SATA III device will be starved for bandwidth.

>>321420
The only PCI/e card I have in the pc is a gpu.

Maybe it's just userbenchmark then huh