Your thread pattern looks good. However you should only multithread things that actually need it. If something executes really fast, the synchronization between the threads are going to make it slower. The best is probably to keep the number of threads dynamic. That way you can adapt the number of threads to the workload.
Yes, I’ve said this a couple of time. And there’s also a logical reason an OS or filesystem might treat these conditions differently (even if none do in actuality).
Huh? Well, the system reports ncq is enabled, and the queue depth as 31.
I’m intrigued from what I understand of ncq (given that my knowledge in this area could be counted on the fingers of no hands 
) why the results I reported above would suggest this - I would have thought the opposite.
unless your disk is fragmented, writing files sequentially like that should be faster without ncq (although probably the rest of your system would benefit from ncq). I guess this wasn’t the main factor though
then my 2nd point applies, which is that the queue can’t be processed in time when you continuously add requests that can’t be completed in time making the queue fill up, causing writing/reading to slow at a constant rate as more things which need to be queued are slowly more delayed at being queued (as long as you are writing/reading at a constant, fast rate)
realistically, unless your running some popular website (i.e. not minecraft), you will not be writing/reading at this rate so this will never become a problem.
Seems you have a bit of an attitude. SSDs have a limited number of program/erase cycles. The 750gb HDD should be faster than 37MB/s.
I… I’m sorry… I didn’t mean to insult you with my ingenious jokes… FYI I do own an SSD, and I’m full aware of the limited number of writes you can do.
Not insulted, just sarcasm out of the blue seemed odd.
And this is why you should avoid siding with people in situations where you have no knowledge of the topic concerned, especially when you have nothing to contribute. 
Jesus, why are people so sensitive? And “related to the topic”? This thread went OT from page one. >_>
Sorry ??? , still don’t get what point you’re trying to make here, or how it relates to the results I posted. Are you saying this is the reason that the throughput for 1 file is slower because of this, or that this explains why I get consistent throughput no matter how many files are being written to? It sounds more like an argument for throughput decreasing, though that may be how I’m reading what you’ve written.
I understand how queue saturation through memory use and ultimately drive write speed should be the limiting factor in a filesystem that can handle multiple concurrent writes effectively (which ext4 seems to be getting closer to). Would I be right to suspect that all / most of those who have posted results to Riven’s code have NCQ enabled, and therefore the relevant differences are queuing in the OS / filesystem and not the hardware?
Quite! This was the post that made me want to join in this discussion, and read a bit more about the issues - as someone with no knowledge of the topic, I felt perfectly placed to jump in and side with no-one! ;D
Yes to your last point.
Did you try running my test by the way?
It’s fun taking sides,especially when I learn about this stuff after you guys explain it ;D