Jump to content


Photo

16GB CF cards now shipping.


  • Please log in to reply
5 replies to this topic

#1 Matt Garrett

Matt Garrett
  • Basic Members
  • PipPip
  • 39 posts
  • Camera Operator

Posted 18 July 2008 - 08:14 PM

http://www.reduser.n...ead.php?t=16522
  • 0

#2 Keith Walters

Keith Walters
  • Sustaining Members
  • 2252 posts
  • Other
  • Sydney Australia

Posted 19 July 2008 - 12:04 AM

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?
  • 0

#3 Glen Alexander

Glen Alexander
  • Guests

Posted 19 July 2008 - 08:07 AM

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,
  • 0

#4 Keith Walters

Keith Walters
  • Sustaining Members
  • 2252 posts
  • Other
  • Sydney Australia

Posted 21 July 2008 - 04:50 AM

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.
  • 0

#5 Chris Kenny

Chris Kenny
  • Basic Members
  • PipPipPipPip
  • 264 posts
  • Other

Posted 21 July 2008 - 05:09 PM

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.
  • 0

#6 John Sprung

John Sprung
  • Sustaining Members
  • 4635 posts
  • Other

Posted 21 July 2008 - 05:32 PM

The major advantage of C is that it allows you to write your own, very fast executing code modules.

Wow, the stuff kids believe these days.... "C" is bloated and inefficient by the standards of us old assembly farts. ;-)




-- J.S.
  • 0


Media Blackout - Custom Cables and AKS

Gamma Ray Digital Inc

Paralinx LLC

Willys Widgets

Ritter Battery

Metropolis Post

Broadcast Solutions Inc

Visual Products

Wooden Camera

CineTape

CineLab

Tai Audio

Rig Wheels Passport

New Pro Video - New and Used Equipment

Glidecam

The Slider

Technodolly

Abel Cine

Aerial Filmworks

rebotnix Technologies

FJS International, LLC

Willys Widgets

Ritter Battery

Visual Products

Tai Audio

Abel Cine

Gamma Ray Digital Inc

Metropolis Post

Rig Wheels Passport

Wooden Camera

The Slider

Paralinx LLC

Media Blackout - Custom Cables and AKS

rebotnix Technologies

CineTape

New Pro Video - New and Used Equipment

CineLab

FJS International, LLC

Aerial Filmworks

Broadcast Solutions Inc

Technodolly

Glidecam