Why are read / write sequential and not parallel

You made a very long list which I am not going to answer one by one. However I want to make these things very clear:

1) PCI can not sustain those speeds. PCI express can, it is a totally different technology with point to point links (called lanes) instead of a shared bus. The card you linked to is " PCIe x4". The extra e is very much relevant.

2) Stripes (RAID 0, RAID10 etc etc) is quite possible. Either with a dozen high performance disks. Or you could use normal disks. An office corner shop, bog standard 7200 RPM SATA drive will do about 100MB/sec. So you would need at least a dozen of these (since things never scale quite perfect).

3) Both HW RAID, software RAID and Fake RAID (software RAID with BIOS supports, e.g. Intel IRSST) will work.

Software RAID is not recommended if you do not to do a lot of calculations (e.g. RAID6) and need high performance or have a slow CPU.

Hardware RAID will vary. A good HW RAID card is great. A bad one might perform quite poorly compared to a good SW RAID solution. Good HW RAID often needs battery backed cache or flash to enable the fast modes.

4) SATA II or III (3.0 or 6.0 GB/sec) or SAS 3GBIT/sec, SAS 6GBIT SEC, ... does not matter. And individual spinning disk will not saturate any of these links. Current consumer SATA drives max out around 100MB/sec. High end enterprise SAS drives can get up to 200MB/sec. Both speeds are lower than 3.0GB/sec.

5) RAID0 is not very safe. If one disk fails, you loose all. This might be acceptable if you just need to test things and save the data. And them immediately save it somewhere safe of process it. However a the more disks you use the more disks can fail.

RAID is usually about redundancy. RAID0 is not, it is solely about performance.

6) Lastly for completeness sake: SSD is not inherently bad for this. For this much data they will be expensive and possibly not needed, but an SSD does not need to slow down. Just completely wipe the SSD (e.g. delete all partitions, or secure erase it) before you add it to recording array. Once it is full it may slow down. But properly prep it and run it for one session and it should be fine.

7)

AHCI is the only BIOS setting relevant to fast sequential writes (turn on SMART too).

You can not turn SMART on or off. It is always on on the drive. The option in the BIOS just means 'read the drives SMART data when you POST and if there is anything wrong then warn the user. Usually with a single line like 'SMART: DISK FAILURE IMMINENT. Press F1 to continue!". It has no performance influence.

Set both of these before installing Windows.

For consistent performance: Install the OS on its own drive. Keep separate volumes for OS and for data.

8)

T sustain 1GB/sec indefinitely, you need >3 7200RPM 6Gb/sec SATA drives (6Gb/sec * 1/8 GB/Gb = .75 GB/sec/drive with no headroom).

No.

A 6GBit/sec data link SATA drive will be able to transfer roughly 300MiB/sec between disk and controller/RAID card. (6.0 divided by 8 for bit-to-bytes, but there is also some overhead and a /10 is more realistic).

Secondly the drive will be able to receive the data quite quickly, but writing it to a disk will be slower. A realistic value for a modern 7200 RPM SATA drive is 100MiB/sec sustained write.

That means you need at least 10 such drives. And only if everything scales perfectly.

More drives will improve your bandwidth headroom linearly, but saturate after the data width of your bus (32 or 64).

True for PCI. But despite writing PCI the OP meant PCI-e, which is a lot faster. 4 lanes PCI-e v2 is up to 10Gbit/sec. That should be enough (though there is not much headroom).

TL;DR: It is because the SSD is lying to you and saying the write is done before it is. It can't get away with the same thing for reads.

The longer version of the answer is write caching.

Lets start with the QD1 case. The SSD will report the write as finished to the OS once it has received the data and saved it in a cache locally on the drive, but before it has actually written it to the NAND. This makes a big difference because actually writing data to NAND is quite slow. For reads it actually has to read the data from NAND before it can send it back (unless it has read it earlier and still has it in cache, but that is very unlikely with random reads).

The downside of this is that in the face of sudden power loss there can be data loss of data written to the SSD but which hasn't made it to the NAND yet. Some enterprise SSDs include a super capacitor which stores enough power to finish writing the data in cache to NAND in case of sudden power loss.

You see the same thing for hard drives because they are also doing write caching. They are just not being nearly as aggressive about it. Why is the SSD so aggressive? To answer that we need to move to consider the QD32 case, which is both more complicated and more interesting.

It is not true what you say that random reads are generally faster than random writes at QD32. It depends a lot on which particular SSDs you look at.

If you look at 4k QD1 random reads on many SATA SSDs they all seem to perform in the 20-30 MB/s range. Why is that? It is because 4k QD1 random reads is mostly about latencies and not throughput. The latency comes from three parts:

1. The interface latency of SATA/AHCI which involves telling the drive what to do and sending the data.
2. The controller itself has to figure out what to do with the data and instructions it has received.
3. The time it takes to actually read or write the data to a NAND die.

Neither 1. or 3. changed much in a long time, and that is why the 1k QD1 random reads didn't change much either.

The recent move in SSDs from SATA/AHCI to PCIe/NVMe has greatly cut down the latency of 1., which is why certain m.2 and PCIe SSDs recently have show great improvements here.

One thing an SSD controller can do to greatly help with the latency is read or write to multiple NAND dies in parallel and that way mask most of the latency of 3. If you are doing QD32 4k random reads with NCQ the SSD can service the read requests out of order and make sure it is reading from as many NAND dies in parallel as possible.

For QD32 4k random writes the SSD does something called write combining. When a lot of small write requests comes in the SSD controller caches them locally and when a big enough buffer of writes has built up the controller splits it into nicely sized chunks and writes the chunks to multiple NAND dies in parallel, again to help mask the NAND latency. Another advantage of write combining is that most SSDs nowadays have a page size (smallest amount that can be read or written) bigger than 4k, and combining writes until you get up to the page size helps avoid lots of write amplification. It is in order to do these thing that SSDs are so aggressive in write caching.