Hello!
I'm relatively new to linux (been working with it for 7 or 8 months
now), primarily using and contributing to the Porteus Linux community.
Porteus is a distro that is optimized to run from a cd, USB flash
drive, CF, SD, or other portable bootable media. As such, I'm trying
to improve my knowledge of how flash devices work and how to best
optimize them for use under linux (and, thus, it seems we may have
some common goals).
Arnd, your article at LWN as well as the information you've posted at
linaro and to this mailing list has been a great help to me -- thank
you for your time and efforts!
I have three flash drives ( an 8GB Kingston DataTraveller DT101 G2,
which doesn't seem to match up with the results you've already posted
on the flash card survey for an 8GB DataTraveller, a 4GB Lexar
JumpDrive TwistTurn, and an old 1GB USB1.1 unnamed drive that I
received as a gift). I benched the Kingston and Lexar models
yesterday, but somehow flashbench or one of the other commands I ran
during the process wiped out the MBR and partition tables on both
drives, and I've lost almost all of my data. The only thing I've been
able to salvage so far is the results for the Lexar drive. I'll send
along results for the others, and if I can figure out what I did to
hose my drives I'll report on that as well (if you have any good
recommendations for recovering data, I'm all ears! I've tried
testdisk, dd_rescue, and scalpel without much luck --this could just
be my lack of skill lol. Scalpel was able to get some text scattered
around, which is how I got the Lexar results back).
Ok, on to the results:
## Note -- this drive is 2-3 years old, give or take.
bash-4.1# Bus 002 Device 004: ID 05dc:a764 Lexar Media, Inc.
bash-4.1# fdisk -lu /dev/sdc
Disk /dev/sdc: 4009 MB, 4009754624 bytes
128 heads, 16 sectors/track, 3824 cylinders, total 7831552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x77ac9c58
Device Boot Start End Blocks Id System
/dev/sdc1 * 49152 3637247 1794048 83 Linux
/dev/sdc2 3637248 7831551 2097152 83 Linux
bash-4.1#
## In an effort to improve performance without really knowing the
erasesize of this drive, I started my partitions on 24MB intervals
(least common denominator for all of the common allocation unit sizes
on the flash card survey) and set my cylinder size to be one MB (I
don't know if cylinder size, sectors/track, etc., really matters,
since the FS block sizes don't match up to the page sizes anyway, but
I thought it was worth a try). However, this didn't really help my
performance very much. I should note that partition sdc1 was actually
formatted as FAT32, and sdc2 was formatted as EXT4.
bash-4.1# hdparm -I /dev/sdc
/dev/sdc:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00
00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
bash-4.1#
cat /proc/partitions
8 32 3915776 sdc
8 33 1794048 sdc1
8 34 2097152 sdc2
bash-4.1# ./flashbench -a /dev/sdc --blocksize=1024 --count=100
align 1073741824 pre 846µs on 867µs post 849µs
diff 19.8µs
align 536870912 pre 817µs on 866µs post 815µs diff 49.2µs
align 268435456 pre 809µs on 855µs post 811µs diff 45.3µs
align 134217728 pre 819µs on 856µs post 794µs diff 49.6µs
align 67108864 pre 814µs on 857µs post 808µs diff 45.6µs
align 33554432 pre 809µs on 857µs post 806µs diff 49.5µs
align 16777216 pre 818µs on 862µs post 813µs diff 46.2µs
align 8388608 pre 808µs on 861µs post 805µs diff 54.7µs
align 4194304 pre 798µs on 857µs post 804µs diff 56.3µs
align 2097152 pre 833µs on 862µs post 814µs diff 38.1µs
align 1048576 pre 829µs on 881µs post 818µs diff 57µs
align 524288 pre 829µs on 884µs post 826µs diff 56.2µs
align 262144 pre 849µs on 886µs post 807µs diff 58.1µs
align 131072 pre 849µs on 876µs post 832µs diff 35.8µs
align 65536 pre 837µs on 884µs post 824µs diff 53.7µs
align 32768 pre 824µs on 883µs post 831µs diff 55µs
align 16384 pre 833µs on 881µs post 833µs diff 48.7µs
align 8192 pre 832µs on 875µs post 820µs diff 48.6µs
align 4096 pre 827µs on 880µs post 831µs diff 51.4µs
align 2048 pre 833µs on 821µs post 831µs diff -11049n
bash-4.1#
##I wasn't sure, but I assumed that this means I have a 4MB erase
block -- my numbers were even more inconsistent before I added the
count=100 option. I also made a number of scatter plots for this
drive, with and without offsets to different locations on the drive,
and it showed a straight line for 24+MB (whereas my kingston drive
showed very clear jumps at 4MB intervals).
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024
4MiB 6.62M/s
2MiB 7.08M/s
1MiB 7.05M/s
512KiB 7.05M/s
256KiB 7.09M/s
128KiB 7.1M/s
64KiB 7.1M/s
32KiB 7.03M/s
16KiB 6.92M/s
8KiB 6.64M/s
4KiB 2.79M/s
2KiB 1.29M/s
1KiB 620K/s
bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024
4MiB 7.42M/s
2MiB 7.4M/s
1MiB 7.34M/s
512KiB 6.19M/s
256KiB 7.36M/s
128KiB 7.34M/s
64KiB 7.35M/s
32KiB 7.28M/s
16KiB 7.13M/s
8KiB 6.83M/s
4KiB 2.8M/s
2KiB 1.28M/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024
4MiB 6.48M/s
2MiB 5.46M/s
1MiB 7.4M/s
512KiB 7.39M/s
256KiB 7.34M/s
128KiB 7.35M/s
64KiB 7.34M/s
32KiB 7.26M/s
16KiB 7.11M/s
8KiB 6.83M/s
4KiB 2.81M/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024
4MiB 6.8M/s
2MiB 5.8M/s
1MiB 7.32M/s
512KiB 5.83M/s
256KiB 7.36M/s
128KiB 7.33M/s
64KiB 7.34M/s
32KiB 7.26M/s
16KiB 7.12M/s
8KiB 6.8M/s
4KiB 2.8M/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=5 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024
4MiB 6.95M/s
2MiB 6.06M/s
1MiB 7.34M/s
512KiB 4.22M/s
256KiB 1.45M/s
128KiB 675K/s
^C
--> 4 open linear AU's?
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
4MiB 6.86M/s
2MiB 5.81M/s
1MiB 7.33M/s
512KiB 3.39M/s
256KiB 1.39M/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
4MiB 5.44M/s
2MiB 4.88M/s
1MiB 7.34M/s
512KiB 4.45M/s
256KiB 4.95M/s
128KiB 2.7M/s
64KiB 4.98M/s
32KiB 2.88M/s
16KiB 2.85M/s
8KiB 1.65M/s
4KiB 960K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
4MiB 4.79M/s
2MiB 5.99M/s
1MiB 5.44M/s
512KiB 4.41M/s
256KiB 1.53M/s
128KiB 941K/s
64KiB 540K/s
^C
bash-4.1#
--> only 1 open random AU?
Or, I got the erasesize wrong, and there are two:
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random
2MiB 7.09M/s
1MiB 2.68M/s
512KiB 7.26M/s
256KiB 3.57M/s
128KiB 4.12M/s
64KiB 3.63M/s
32KiB 2.47M/s
16KiB 2.53M/s
8KiB 2.2M/s
4KiB 960K/s
2KiB 436K/s
^C^[[A
bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc
--erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random
2MiB 5.1M/s
1MiB 7.42M/s
512KiB 4.85M/s
256KiB 4.37M/s
128KiB 2.86M/s
64KiB 6.73M/s
32KiB 2.81M/s
16KiB 2.21M/s
8KiB 1.98M/s
4KiB 866K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc
--erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random
2MiB 4.32M/s
1MiB 5.91M/s
512KiB 4.11M/s
256KiB 1.39M/s
128KiB 998K/s
64KiB 619K/s
^C
bash-4.1#
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[4 *
1024*1024] --random --blocksize=512 /dev/sdc
4MiB 3.8M/s 3.59M/s 7.41M/s 7.39M/s 7.37M/s
2MiB 3.54M/s 4.34M/s 5.48M/s 7.37M/s 7.4M/s
1MiB 3.54M/s 4.33M/s 5.5M/s 7.39M/s 7.41M/s
512KiB 4.24M/s 3.33M/s 3.36M/s 4.01M/s 4.44M/s
256KiB 4.24M/s 3.06M/s 2.7M/s 2.71M/s 2.71M/s
128KiB 3.78M/s 2.83M/s 2.72M/s 2.72M/s 2.72M/s
64KiB 2.96M/s 2.72M/s 2.4M/s 2.4M/s 2.4M/s
32KiB 3.23M/s 2.81M/s 2.67M/s 2.67M/s 2.67M/s
16KiB 2.57M/s 2.47M/s 2.47M/s 2.47M/s 2.46M/s
8KiB 1.67M/s 1.87M/s 1.87M/s 1.87M/s 1.87M/s
4KiB 1.03M/s 951K/s 882K/s 814K/s 816K/s
2KiB 464K/s 466K/s 436K/s 411K/s 411K/s
^C
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[2 *
1024*1024] --random --blocksize=512 /dev/sdc
2MiB 4.25M/s 7.07M/s 3.07M/s 4.34M/s 7.39M/s
1MiB 7.11M/s 3.05M/s 3.05M/s 4.41M/s 7.38M/s
512KiB 4.27M/s 3.08M/s 3.03M/s 2.72M/s 3.64M/s
256KiB 4.17M/s 3.54M/s 3.54M/s 2.4M/s 2.39M/s
128KiB 2.95M/s 2.99M/s 2.97M/s 2.73M/s 2.74M/s
64KiB 4.12M/s 2.98M/s 2.98M/s 2.29M/s 2.3M/s
32KiB 2.8M/s 2.21M/s 2.21M/s 2.53M/s 2.54M/s
16KiB 2.6M/s 2.06M/s 2.6M/s 2.58M/s 2.58M/s
8KiB 1.54M/s 1.81M/s 1.82M/s 1.81M/s 1.19M/s
4KiB 1.03M/s 940K/s 791K/s 969K/s 829K/s
^C
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[1 *
1024*1024] --random --blocksize=512 /dev/sdc
1MiB 2.97M/s 3.05M/s 3.1M/s 3.08M/s 3.12M/s
512KiB 3.02M/s 7.04M/s 3.02M/s 3.02M/s 3.03M/s
256KiB 6.95M/s 3.02M/s 6.99M/s 6.93M/s 6.93M/s
128KiB 1.87M/s 2.97M/s 2.98M/s 1.87M/s 1.86M/s
64KiB 6.75M/s 6.79M/s 6.81M/s 2.89M/s 6.84M/s
32KiB 1.33M/s 2.81M/s 2.85M/s 2.83M/s 2.84M/s
16KiB 1.73M/s 2.61M/s 2.63M/s 1.72M/s 2.61M/s
8KiB 1.18M/s 2.23M/s 1.55M/s 2.23M/s 2.22M/s
4KiB 1.04M/s 1.04M/s 866K/s 1.04M/s 1.05M/s
2KiB 504K/s 459K/s 458K/s 504K/s 420K/s
^C
bash-4.1#
--> all very unclear to me.
##with the following, I'm trying some offsets to confirm the
eraseblock size. I wasn't able to sort anything very useable out of
this.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
--offset=$[123*512]
4MiB 3.99M/s
2MiB 3.38M/s
1MiB 4.02M/s
512KiB 3.97M/s
256KiB 3.29M/s
128KiB 3.74M/s
64KiB 2.74M/s
32KiB 2.46M/s
16KiB 1.69M/s
8KiB 1.43M/s
4KiB 756K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
--offset=$[28*1024*1024]
4MiB 5.48M/s
2MiB 7.44M/s
1MiB 7.42M/s
512KiB 3.67M/s
256KiB 4.82M/s
128KiB 2.71M/s
64KiB 5M/s
32KiB 2.89M/s
16KiB 2.86M/s
8KiB 1.66M/s
4KiB 964K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
--offset=$[29*1024*1024]
4MiB 3.76M/s
2MiB 5.46M/s
1MiB 7.36M/s
512KiB 4.86M/s
256KiB 4.82M/s
128KiB 2.71M/s
64KiB 5M/s
32KiB 2.89M/s
16KiB 2.51M/s
8KiB 1.66M/s
4KiB 963K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
--offset=$[30*1024*1024]
4MiB 3.49M/s
2MiB 7.27M/s
1MiB 4.08M/s
512KiB 5.55M/s
256KiB 3.84M/s
128KiB 3.11M/s
64KiB 4.03M/s
32KiB 3.35M/s
16KiB 2.87M/s
8KiB 1.63M/s
4KiB 968K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random
--offset=$[57*512*1024]
4MiB 4.02M/s
2MiB 4.6M/s
1MiB 6.33M/s
512KiB 3.18M/s
256KiB 3.48M/s
128KiB 2.23M/s
64KiB 1.33M/s
32KiB 906K/s
^C
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random
--offset=$[57*512*1024]
1MiB 3.15M/s
512KiB 7.21M/s
256KiB 6.9M/s
128KiB 1.91M/s
64KiB 6.63M/s
32KiB 6.13M/s
16KiB 1.59M/s
8KiB 3.8M/s
4KiB 950K/s
2KiB 419K/s
1KiB 216K/s
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random
--offset=$[61*512*1024]
1MiB 5.3M/s
512KiB 4.38M/s
256KiB 3.04M/s
128KiB 6.81M/s
64KiB 6.64M/s
32KiB 1.6M/s
16KiB 5.12M/s
8KiB 1.38M/s
4KiB 985K/s
2KiB 466K/s
1KiB 221K/s
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc
--erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random
--offset=$[123*256*1024]
1MiB 3.04M/s
512KiB 6.96M/s
256KiB 7.07M/s
128KiB 2.98M/s
64KiB 6.71M/s
32KiB 2.21M/s
16KiB 1.74M/s
8KiB 3.83M/s
4KiB 888K/s
2KiB 389K/s
1KiB 218K/s
bash-4.1#
If you have more tests you would like performed, I can do them, once I
am either done recovering data or give up on it. I'm very perplexed
by this drive, because it was very clear to see the 4MB units in the
kingston drive, both with the flashbench -a test and on the scatter
plot. I spent the last couple of weeks benchmarking this drive with a
script that I wrote, to try out various filesystems that work best
with the Porteus operating system. I ran a substantial amount of
tests with it improperly aligned, and got only a slight improvement
when I aligned it to start partitions on 24MB blocks, so I guess it's
not surprising that the eraseblock boundaries are difficult to find!
I am curious to know what kind of improvements you see (or expect to
see) when a drive is in versus out of alignment (and I'll be
benchmarking my kingston drive to test this out as well). This
information will likely be of great interest to our community.
If I can sort out and resolve the cause for my drives getting wasted,
I'll also recommend the flashbench tool to other users, and collect
their results for your flashcard survey.
Thanks again!
-Ahau
[i do not shorten this msg because it was not going to the
list because i did not reply to list]
On 08/07/11 22:41, Arnd Bergmann wrote:
> On Friday 08 July 2011 19:36:56 Peter Warasin wrote:
>> Hi Arnd
>>
>> thank you for your help!
>>
>> On 08/07/11 16:55, Arnd Bergmann wrote:
>>> but there is a problem using three or more. However, the
>>> performance is still basically constant, so the card is
>>> doing something smart. It's probably using the new Sandisk
>>> trick with SLC and MLC areas. On the one hand, this is
>>
>> ah, so the journaling of ext3 *should* not be a problem, right?
>
> The journaling normally makes things worse, but by how much
> depends on the card characteristics. Sometimes it's almost
> nothing, sometimes it's orders of magnitude. In this case,
> the answer is probably "noticeable, but not drastic".
>
>>> good news, because the card doesn't behave that badly,
>>> on the other hand it's not easy to measure and the baseline
>>> of 2 MB/s is rather slow.
>>
>> I see. So this means aligning to 4MB is a good thing?
>> Or does this simply mean i can write 2 blocks at once?
>
> 4 MB alignment is always the right thing.
>
>>> It's still not all that bad. If you want to try other things,
>>> first of all try the same with the class 10 card. Also, add the
>>> '--random' flag to see if it changes anything. Any measurements
>>> with '--random' are more likely to be useful than those without,
>>> but it may be that the class 10 card won't like that argument
>>> and becomes extremely slow.
>>
>> our class10 is a transcend card, so making tests with this card is like
>> comparing apples with pears i think. maybe the quality of that card is
>> also not the best.
>> we try to get a class6 and class10 sandisk
>
> Transcend cards vary extremely in their quality. Even comparing two
> Transcend cards with identical labels can sometimes be apples and
> oranges (or pears). Some that I've seen are quite ok, others are
> absolutely horrible.
>
> If you want to experiment more with flashbench, I suggest trying the
> transcend card first, it will give you much more understandable
> results, because in my experience the controllers are so much simpler
> there.
ok, will try that monday and send results..
>> but what --random does, isn't that more likely what a normal system does
>> on the SD card when i have /var and swap on the SD card?
>> so this means it is quite normal that it will be very slow, is it?
>
> Yes. If the card is this bad at random access, it won't work well with
> Linux at all. You can either try to get a better card right away, or
> continue figuring out what the card actually does. It's getting quite
> interesting here, I think.
>
>> same test with --random:
>>
>> ./flashbench -O --open-au-nr=2 --random /dev/mmcblk0p3
>> 4MiB 839K/s
>> 2MiB 3.26M/s
>> 1MiB 8.7M/s
>> 512KiB 1.48M/s
>> 256KiB 731K/s
>> 128KiB 952K/s
>> 64KiB 1.18M/s
>> 32KiB 594K/s
>> 16KiB 356K/s
>>
>> i guess i should align to 1MB then?
>
> No, different issue. This card is rather tricky and what it probably
> does is clean during long writes after smaller writes. If you
> do "./flashbench -O --open-au-nr=2 --random /dev/mmcblk0p3 --blocksize=$[1024*1024]"
> a few times repeatedly, it should get better at the second or third
> run. You can normally ignore any odd results in the first one or
> two rows of a test run for this reason.
yes, it does, however it has very varying values when starting it a
couple of times. from 2x faster to all slow.
is the garbage collector slow and running all the time after 2nd try?
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O
4MiB 2.16M/s
2MiB 2.86M/s
1MiB 4.2M/s
512KiB 1.47M/s
256KiB 735K/s
128KiB 904K/s
64KiB 1.12M/s
32KiB 550K/s
16KiB 360K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O
4MiB 3.5M/s
2MiB 6.58M/s
1MiB 9.5M/s
512KiB 1.49M/s
256KiB 734K/s
128KiB 986K/s
64KiB 1.17M/s
32KiB 589K/s
16KiB 369K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O
4MiB 647K/s
2MiB 603K/s
1MiB 604K/s
512KiB 631K/s
256KiB 745K/s
128KiB 987K/s
64KiB 1.17M/s
32KiB 588K/s
16KiB 309K/s
# ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O
4MiB 652K/s
2MiB 599K/s
1MiB 604K/s
512KiB 636K/s
256KiB 736K/s
128KiB 1M/s
64KiB 1.16M/s
32KiB 540K/s
16KiB 352K/s
what i also noticed on this card is that the card is running with legacy
timing instead of high-speed:
cat /sys/kernel/debug/mmc0/ios
clock: 25000000 Hz
vdd: 20 (3.2 ~ 3.3 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 0 (legacy)
i tried to figure out why, but most probably i guess the card will
respond with SCR_SPEC_VER_1 for sda_vsn i *think*, since the controller
(marvell/mvsdio) is MMC_CAP_SD_HIGHSPEED capable and i see no kernel
warnings that the card is not able to do mandatory switch function
will try to hardcode to SD_HIGHSPEED next week.. (for testing)
could that help or is it completely irrelevant?
> The result can mean one of two things:
>
> * the erase block size is something other than 4 MB, and you first need
> to figure out the correct size to rerun it.
> * The card can not actually do random writes at all, which is unusual
> for Sandisk cards, but is something I've seen before in a few cases.
>
>> ./flashbench -O --open-au-nr=3 --random /dev/mmcblk0p3
>> 4MiB 2.84M/s
>> 2MiB 2.46M/s
>> 1MiB 5.23M/s
>> 512KiB 1.33M/s
>> 256KiB 697K/s
>> 128KiB 1.08M/s
>> 64KiB 904K/s
>> 32KiB 534K/s
>> 16KiB 360K/s
>>
>> ./flashbench -O --open-au-nr=5 --random /dev/mmcblk0p3
>> 4MiB 2.87M/s
>> 2MiB 2.56M/s
>> 1MiB 1.71M/s
>> 512KiB 1.78M/s
>> 256KiB 920K/s
>> 128KiB 471K/s
>> 64KiB 320K/s
>> 32KiB 276K/s
>> 16KiB 215K/s
>
> Not much to see here, it only shows that the card isn't all
> that great for random access.
>
>>> You can get measurements for smaller block sizes in addition to
>>> the values down to 16KB by passing --blocksize=512. This may get
>>> rather slow towards the end, but is very relevant because the
>>> block size used by ext3 is only 4KiB.
>>
>> ah great.
>> ok, did i understand right that i do this tests for figuring out the
>> actual values of erase block size and blocksize?
>> when i know those values, what do i do with them? align partitions to
>> erase block size and format filesystem with SD blocksize (if possible)?
>
> Correct for erasesize, that should be the partition alignment. Possible
> values here are 1.5MB, 2MB, 3MB, 4MB, 6MB and 8 MB, I haven't seen
> anything else with SD cards yet.
>
> The blocksize argument you pass to flashbench only affects how many
> tests are done. By default, it assumes blocksize=16384 and stops there,
aaah, i understand.
> but you can pass any other blocksize that is a multiple of 512
> and a power-of-two fraction of the erasesize. When you pass blocksize=512,
> flashbench will print five more lines of output, but typically get
> very slow. The blocksize that you should use in the file system is the
> smallest number where flashbench gives a non-catastrophic result.
> Often you see something like
>
> ...
> 64KiB 3.2M/s
> 32KiB 2.0M/s
> 16KiB 1.6M/s
> 8KiB 821K/s
> 4KiB 401K/s
> 2KiB 198K/s
> 1KiB 90K/s
> 512 43K/s
>
> In that example, the block size would be 16KB: As you can see, writing
> an 8KB block actually takes longer than writing a 16KB block, so it's
> never worth it from a performance PoV.
>
>> i guess ideal for the SD card performance would be to format with 4MiB
>> blocksize, but that's impossible with ext3 and bad for me because i
>> waste to much space with small files, right?
>
> The largest block size supported by any Linux file system today is 4KB,
> but we're working on increasing that to 64KB, which is quite wasteful.
ah good.
so right now best i can do is using 4k blocksize for the filesystem,
even when this is not the ideal size.
>> is the copy-on-write feature of btrfs maybe helping?
>
> definitely.
great. will do that
>> what about swap .. does it make sense creating a swap with
>> 4MiB pagesize?
>
> You can't. The swap page size is a property of the CPU, you don't get to
> choose it.
ah ok.
>> last question, hope i do not stress you to much:
>
> Don't worry. But please try to figure out any cards that you have access
> to and send the results to the mailing list, so I can add it to the
> database. We have around 100 devices in there today, but every new
> addition helps make us the right choices when optimizing the file
> systems.
ah well, will do my best when we get new cards, which i hope, since i
have to solve this problem somehow :)
>> during bonnie tests we had a high cpu load (90%),.. and during normal
>> operation of the system iowait is going up really high (90%) which
>> freezes the system then
>>
>> is that normal? shouldn't most calculation being done by the
>> microcontroller on the SD chip?
>
> I haven't tried it, but bonnie is really totally useless on SD cards,
> and it's absolutely possible that this is always the case.
it's always the case, that the cpu load is that high only with bonnie,
or under normal circumstances?
i ask because someone on #linaro asked me if the device is probably not
dma enabled or in 1-bit mode, which would make sense i think that if it
is not dma enabled it uses cpu for everything..
however, i figured out that it is not in 1-bit mode, it is in 4-bit
mode, good i guess .. but i was not able how to figure out if it is dma
enabled or not. i found nothing in sourcecode but how to disable dma
during loading the module, which does not apply, since the driver is
compiled in.
peter
--
:: e n d i a n
:: open source - open minds
:: peter warasin
:: http://www.endian.com :: peter(a)endian.com
Dear Friend,
Nice day to you!
New items with great price mobile phone here come out, pls check the
attachment to info the ID.
1>4 Cards & 4 Standby
2>Bluetooth
3>2.3" QVGA Screen
4>30W Dual Cameras
5>Support T-Flash Card
6>FM Radio
7>Analog TV(option)
8>JAVA
9>Support Mp3、Mp4
10>colors:blue & red & purple & silver
Anything more you want to know, please send us email.
Best wishes
Juce
Mobile: 86-13424432252
Tel: 86-755-85282599
Fax: 86-755-81752355
E-mail: elink(a)vip.188.com
Web size: www.oemmobile.com
Factory Address: 5/F, Building 21, ChenTian Industrial Park, Shenzhen,
GuangDong Province, China
Dear Friend,
Nice day to you!
New items with great price mobile phone here come out, pls check the
attachment to info the ID.
1>4 Cards & 4 Standby
2>Bluetooth
3>2.3" QVGA Screen
4>30W Dual Cameras
5>Support T-Flash Card
6>FM Radio
7>Analog TV(option)
8>JAVA
9>Support Mp3、Mp4
10>colors:blue & red & purple & silver
Anything more you want to know, please send us email.
Best wishes
Juce
Mobile: 86-13424432252
Tel: 86-755-85282599
Fax: 86-755-81752355
E-mail: elink(a)vip.188.com
Web size: www.oemmobile.com
Factory Address: 5/F, Building 21, ChenTian Industrial Park, Shenzhen,
GuangDong Province, China
Dear Friend,
Nice day to you!
New items with great price mobile phone here come out, pls check the
attachment to info the ID.
1>4 Cards & 4 Standby
2>Bluetooth
3>2.3" QVGA Screen
4>30W Dual Cameras
5>Support T-Flash Card
6>FM Radio
7>Analog TV(option)
8>JAVA
9>Support Mp3、Mp4
10>colors:blue & red & purple & silver
Anything more you want to know, please send us email.
Best wishes
Juce
Mobile: 86-13424432252
Tel: 86-755-85282599
Fax: 86-755-81752355
E-mail: elink(a)vip.188.com
Web size: www.oemmobile.com
Factory Address: 5/F, Building 21, ChenTian Industrial Park, Shenzhen,
GuangDong Province, China
Dear Customer (Manager),
Good day!
New items with great price mobile phone here come out, pls check the
attachment to info the ID.
1>4 Cards & 4 Standby
2>Bluetooth
3>2.3" QVGA Screen
4>30W Dual Cameras
5>Support T-Flash Card
6>FM Radio
7>Analog TV(option)
8>JAVA
9>Support Mp3、Mp4
10>colors:blue & red & purple & silver
If you need the detail requirement, please don't hesitate to contact us.
Best wishes
Juce
Mobile: 86-13424432252
Tel: 86-755-85282599
Fax: 86-755-81752355
E-mail: elink(a)vip.188.com
Web size: www.oemmobile.com
Factory Address: 5/F, Building 21, ChenTian Industrial Park, Shenzhen,
GuangDong Province, China