16GB CF cards now shipping.

Matt Garrett · July 19, 2008

http://www.reduser.net/forum/showthread.php?t=16522

Keith Walters · July 19, 2008

Has anybody had any experience with quantative speed testing of memory cards?

I've recently been involved in the speed testing of samples USB flash drives.

For a comparative test I wrote a simple Visual Basic applet that writes a file consisting of the binary number 10101010 repeated billions of times. I chose 10101010 on the basis that it should give the maximum number of digital high-to-low transitions, and hence produce maximum heating effect.

The actual code is quite simple:

(for a 4G file)

Dim OneK As String * 1024

Dim i As Long

Close 1: Open "F:\bigfile.tst" for Output As 1

OneK= String(1024, Chr(170))

For i = 1 To 4000000

print #1, OneK;

Next i

The variable "OneK" is simply 10101010 repeated 1024 times, and writing that to the same file 4 million times gives a file length of a little under 4GB. You could make it exactly 4GB (4,294,967,296) by setting the For-Next loop to 4,194,304 iterations, but most flash memory devices cannot hold their full rated capacity, since some space is reserved for the onboard read/write software.

While they system does give results broadly in line with what is expected of the devices being tested, it is not really practical to have direct measurement of the time taken because I have noticed that the VB applet seems to finish some time before the little light on the flash drive stops blinking! Since we are not testing all that many drives, it is easy enough to use a stopwatch, but not of course on the ones mitout der blinkenlampen!

I also tried writing the file to the hard disk first and then seeing how long it takes to copy it across, which gives about the same results. That way the timing can be done by watching the Hard Disc LED.

What I don't know enough about is how the PC knows how fast it can squirt data into the flash drive. I presume the flash drive has some sort of buffer memory which simply asks the PC for more data when it has finished digesting the previous lot.

But if that is the case, is the speed at which this happens pre-set by the manufacturer using the drive's on board clock, or does it just work as fast as it can?

July 19, 2008

the level of your code is not near enough to hardware for meaningful results.

you haven't coded anything about sequential or random access.

VB is bloated, write a command line C or Fortran program or get source and recompile IOmeter, you can benchmark any drive.

use hardware level calls to the OS drivers/DMA

lock the drive

know format of USB drive,

where to align the boundaries,

what chipset bridge it is going through,

what other crap is hanging on the bridge to slow it down,

what priority is the process,

Keith Walters · July 21, 2008

VB is bloated, write a command line C or Fortran program or get source and recompile IOmeter, you can benchmark any drive.

The executable file was just over 20K. This is "bloated"?

OK, I got one of our coke-bottle glasses brigade to write the same application in C, and surprise, surprise, we got exactly the same results. Hardly surprising since most of the VB "Bread and Butter" commands are written in C anyway. We get consistent results within the different brands we have samples of, and that's good enough. Sorry, life beckons....

The major advantage of C is that it allows you to write your own, very fast executing code modules. A VB sub-procedure to do the same job is made up of VB keywords and will naturally execute much more slowly.

On the other hand, you can write extremely complex programs in VB without needing to bear a resemblance to Comic Book Guy, and 99% of the time, they don't need to execute particularly fast anyway.

Chris Kenny · July 21, 2008

Yeah, disk operations (certainly file-level operations) are almost always going to be limited by the disk, not the CPU, so cycle-wasting implementations don't make much difference; the code is still spending almost all of its time waiting for the disk to catch up.