« on: May 25, 2013, 03:52:33 PM »
A comment on the write speed problem, it might be that the CF card has to have good garbage collection, because if you want to write to a NAND block that already has data, you first have to clear it, then write to it. Some of the cheaper ones might not implement that well, and it might be that the better CF card controllers can detect when a card is reformatted (rather than delete files) and mark those blocks to be cleared out in advance of need like the TRIM command that modern SATA SSDs support.
I will test this out. Based on my experience and what you're suggesting, I think the best route will be to fill a card in sequence and then reformat after it fills up. Hell, I won't even preview clips. After I get sustained speeds, I can test and figure out what compromises the card speed.
I'm just extrapolating based off of modern SSDs. Ah, looks like CF 6.0 introduced UDMA7, as well as TRIM command just like SSDs have. So I imagine that's what is being used during a delete/quick-format to tell the controller that it no longer needs to keep the NAND blocks permanently, and can clear them out at will. This is part of what the controller garbage collection does, and usually operates in the background. So it might be you need to leave it sitting for a short bit in the camera/reader after deleting/formatting the card to give it power and let it do it's background cleanup to keep maximum performance.
The test you're describing is part of what Ananadtech.com does during it's SSD tests, as well they now check the consistency of latency which can be important to avoid buffer overruns in a case like this, where if it has a brief spike in latency that might reduce overall throughput just enough that you start dropping a few frames.