Hellhammer, would something like this be random writes as far as speeds go? Wouldn't be sequential unless going disk to disk huh? Something that always gave me trouble wrapping my head around.
It should be sequential because it's writing new data and not modifying existing one. Random writes usually occur when you're modifying existing data, such as log files. To save RAM, only the part of the data you need is loaded to RAM and the modified data is then rewritten. The randomness comes from the fact that there may be multiple parts that are loaded but they are not in sequential order, or you're accessing multiple files simultaneously so the controller needs to read/write from non-sequential (i.e. random) LBAs.
A good real world example would be an address book. If you want to access it sequentially, you have to load the whole address book to RAM in order to access just one contact. For example, if you want to add a name that starts with a Y, you first go through all names from A-T until you get to Y (assuming the address book is sorted alphabetically) and then add the new name there. The whole address book is then rewritten. Reading/writing the data is fast since it's sequential but it takes more RAM and CPU.
Random access in this case would be that you only modify and write the Y contacts again. It's random because if you're e.g. viewing a contact that starts with an E and another one that starts with a Y, the IOs are not in sequential (i.e. alphabetical in this example) order so one contact is read from LBA 1 and the other from LBA 17.
I hope this sheds some light. It's definitely quite hard to understand and what makes it even harder is the fact that all apps behave in different ways. One might load the whole address book to RAM and be a RAM hog, while the other may access all contacts separately (i.e. randomly).
Furthermore, an SSD doesn't really care if the data is sequential or random because seek times are essentially non-existent, what matters is the IO size. A big IO can be broken into smaller bits and written to multiple NAND dies simultaneously, which provides great performance. In OP's case each frame is 2.3MB so that's a fairly big transfer.
