On Mon, 2 Mar 2009, Craig Falconer wrote:
Well this is bizarre....
time dd if=/dev/zero of=/file.dd bs=16k count=16k
produces a 256 MB file.
onto sda (4GB) that took 11.34 seconds (27.9 MB/sec)
However onto sdb it took 55.93 seconds (4.8 MB/sec)
So you might be onto something here.
time dd if=/dev/zero of=/file.dd bs=8k count=64k
sda 39.2 sec 13.7 MB/sec
sdb 77.2 sec 6.9 MB/sec
Weird.
Again you're probably testing the speed of ram, not flash.
You need a test something like...
sync;time bash -c 'dd if=/dev/zero of=/file.dd bs=8k count=64k;sync'
sync;time bash -c 'dd if=/dev/zero of=/file.dd bs=8k count=64k;sync'
sync;time bash -c 'dd if=/dev/zero of=/file.dd bs=8k count=64k;sync'
sync;time bash -c 'dd if=/dev/zero of=/file.dd bs=8k count=64k;sync'
The sync to flush any dirty buffers, then the time 'bash -c 'dd
blah;sync' to time the dd AND the sync. Otherwise dd has just written
into ram buffers, which the kernel will flush at leisure.
You also need to do it four times. Once to get the "bash", time and
sync "hot and in cache", three times to check you are getting
variability from other stuff happening.
Bench marking on modern systems is tricksy in extreme.
Usually I find cache effects dominate.
* Does it fit within L1, or L2 or disk buffers or not?
* Is it in some level of cache already?
* Is something squeezing it out of some level of cache? eg. A leaky
humongous javascript app running in your web browser whilst you
testing. (But nothing was running on my machine! A yes there was,
every minute or two the web server spat a new fat flash and
javascript ad at you!)
Remember, Linux tries _hard_ to make use of _all_ your Ram _all_ the
time. It doesn't let it sit there idle and without value.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand
