<div dir="ltr">Oh, I see. Good thought about flushing cache. <br><br>The speeds for read and write are different on a SD card with read being always faster and so I was thinking to do only the read test and to have dd(1) read directly from the device rather than going through the file system - taking the file system code out of the picture since time due to it is a constant factor.<br>
The size of the read buffer won't matter since what was read is given to /dev/null. The speed and buffering of the underlying Glamo driver and SD card will be the only player - which is what I am testing.<br><br>I'll use something like:<br>
<br>time dd if=/dev/mm<whatever the SD device name is> count=512000 bs=1024 of=/dev/null<br><br>..and dividing the value for System time into (512000 * 1024) for the result.<br><br><br><div class="gmail_quote">On Wed, Jul 30, 2008 at 11:07 PM, Mike Montour <span dir="ltr"><<a href="mailto:mail@mmontour.net">mail@mmontour.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Jim Colton wrote:<br>
> Hi Mike,<br>
><br>
> I looked at the code your wrote. It doesn't do anything that 'time dd'<br>
> already can do.<br>
<br>
</div>It includes an fsync() in the timing measurement when writing the file,<br>
and does a posix_fadvise() before reading it back (both intended to make<br>
sure that the I/O is going to the device under test rather than just<br>
hitting cache memory). You can do the same things in a 'dd'-based test,<br>
but it requires a few additional steps.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
support mailing list<br>
<a href="mailto:support@lists.openmoko.org">support@lists.openmoko.org</a><br>
<a href="https://lists.openmoko.org/mailman/listinfo/support" target="_blank">https://lists.openmoko.org/mailman/listinfo/support</a><br>
</div></div></blockquote></div><br></div>