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
  • 2219 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
  • 2219 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


Broadcast Solutions Inc

Gamma Ray Digital Inc

The Slider

Media Blackout - Custom Cables and AKS

CineLab

Metropolis Post

Wooden Camera

Aerial Filmworks

CineTape

Glidecam

Ritter Battery

rebotnix Technologies

Technodolly

Visual Products

Rig Wheels Passport

Willys Widgets

Abel Cine

Tai Audio

Paralinx LLC

FJS International, LLC

Opal

Metropolis Post

Abel Cine

Opal

Glidecam

Broadcast Solutions Inc

Wooden Camera

FJS International, LLC

Visual Products

Gamma Ray Digital Inc

Rig Wheels Passport

Technodolly

Willys Widgets

Paralinx LLC

The Slider

Tai Audio

CineLab

Media Blackout - Custom Cables and AKS

Ritter Battery

CineTape

rebotnix Technologies

Aerial Filmworks