flashbench/dd/fio等工具测试sd卡性能

flashbench on windows

这里写图片描述
windows上的flashbench对u盘读写速度的测试非常简单,他把100M文件写入到盘中,这样就能测试写入速度,然后读取这个文件,从而获取读取速度。
这个软件使用起来也很简单,在界面的”Drive”后面选择u盘对应的盘符,然后点击Benchmark,就开始测试了,测试的结果会在软件的下半部分通过折线图显示出来。
在FlashBench界面的底部,你会看到16MB,8MB,4MB等字。这个代表每次测试时写入的单个文件的大小。由于flash介质在响应时间上会有差异,所以写入多个文件之间是会有间隔的,所以同样是100MB,1KB文件的数量会比16MB文件的多很多,那么传输小文件时实际的读写性能会下降的厉害。


flashbench on linux

下载git clone git://git.linaro.org/people/arnd/flashbench.git
另外一些关于这个软件的参数及使用的讨论http://lists.linaro.org/mailman/listinfo/flashbench-results


align

align测试用于发现erase block size和page size大小。
因为sd卡所用的flash颗粒是有wear leveling的,而现有的操作系统对于如何格式化和访问flash还没有成熟的方案,所以系统默认的格式化方案对于flash的访问速度和life time来说并不是最优的方案,选择一个最佳的erase block size 和page size可以提高sd卡的读写性能和延长使用寿命。

This is just a non-destructive read test. Sometimes read performance when spanning two eraseblocks will be slower than when reading only in one erase block. The “pre” reads just prior to an expected eraseblock boundary, the “on” reads spanning an eraseblock boundary, and the “post” reads just after an eraseblock boundary. Any spot where the “diff” times drop dramatically may indicate the likely eraseblock size or the likely write page size (write page size will always be smaller than an eraseblock).
上面这段话是从别的地方摘过来的,个人理解align测试的主要原理是跨erase block size读取n个字节的时间与在同一个erase block size读取n个字节的时间是不一样的。测试page size的原理也是一样的。

~ # flashbench -a -b 1024 /dev/mmcblk0 
align 2147483648        pre 678us       on 910us        post 682us      diff 230us
align 1073741824        pre 778us       on 1.08ms       post 754us      diff 314us
align 536870912 pre 764us       on 1.02ms       post 736us      diff 271us
align 268435456 pre 744us       on 994us        post 762us      diff 242us
align 134217728 pre 774us       on 1.05ms       post 688us      diff 314us
align 67108864  pre 738us       on 984us        post 725us      diff 253us
align 33554432  pre 756us       on 1.03ms       post 740us      diff 279us
align 16777216  pre 739us       on 1.02ms       post 725us      diff 292us
align 8388608   pre 704us       on 950us        post 694us      diff 251us
align 4194304   pre 694us       on 937us        post 689us      diff 246us
align 2097152   pre 698us       on 825us        post 697us      diff 127us
align 1048576   pre 694us       on 783us        post 701us      diff 85us
align 524288    pre 695us       on 785us        post 706us      diff 84.7us
align 262144    pre 696us       on 784us        post 706us      diff 83.4us
align 131072    pre 691us       on 780us        post 705us      diff 82.5us
align 65536     pre 691us       on 781us        post 704us      diff 82.9us
align 32768     pre 697us       on 786us        post 710us      diff 82.3us
align 16384     pre 702us       on 779us        post 691us      diff 82.4us
align 8192      pre 696us       on 735us        post 698us      diff 37.7us
align 4096      pre 699us       on 735us        post 698us      diff 36.5us
align 2048      pre 700us       on 734us        post 696us      diff 35.5us

通过这个命令可以看出erase size可能为4194304和page size为16384

使用上面这个命令尝试使用不同的-b参数(1024, 2048, 4096…)来找出分布位置比较稳定的erase block size和page size,找出一个稳定的分布参考这篇文章beaglebone black简单入门(三),这个实验中发现了4k * 3 * N作为page是较为规律的,且突变都发生在12M,最后测试在这种情况下读写速度,发现使用24k作为page size,12M作为erase block size是比较好的。我这里在自己的板子上做了实验数据如下,可以看出erase block size比较稳定的分布在4194304,而page size分布在16384。

~ # flashbench -a -b 1024 /dev/mmcblk0 
align 2147483648        pre 672us       on 905us        post 668us      diff 235us
align 1073741824        pre 779us       on 1.07ms       post 751us      diff 308us
align 536870912 pre 767us       on 1.02ms       post 728us      diff 269us
align 268435456 pre 740us       on 997us        post 766us      diff 244us
align 134217728 pre 772us       on 1.04ms       post 683us      diff 315us
align 67108864  pre 730us       on 982us        post 721us      diff 256us
align 33554432  pre 744us       on 1.02ms       post 730us      diff 286us
align 16777216  pre 740us       on 1.03ms       post 728us      diff 293us
align 8388608   pre 694us       on 943us        post 693us      diff 249us
align 4194304   pre 692us       on 936us        post 683us      diff 249us
align 2097152   pre 696us       on 817us        post 693us      diff 123us
align 1048576   pre 693us       on 781us        post 703us      diff 83.5us
align 524288    pre 693us       on 788us        post 707us      diff 87.9us
align 262144    pre 693us       on 780us        post 704us      diff 81.9us
align 131072    pre 691us       on 779us        post 705us      diff 81.3us
align 65536     pre 694us       on 779us        post 701us      diff 81.7us
align 32768     pre 693us       on 785us        post 701us      diff 87.6us
align 16384     pre 701us       on 774us        post 691us      diff 78us
align 8192      pre 695us       on 734us        post 699us      diff 36.7us
align 4096      pre 699us       on 733us        post 699us      diff 34.3us
align 2048      pre 698us       on 732us        post 697us      diff 35.1us
~ # 
~ # flashbench -a -b 2048 /dev/mmcblk0 
align 2147483648        pre 705us       on 921us        post 701us      diff 219us
align 1073741824        pre 792us       on 1.08ms       post 776us      diff 301us
align 536870912 pre 789us       on 1.03ms       post 752us      diff 262us
align 268435456 pre 761us       on 1.01ms       post 785us      diff 234us
align 134217728 pre 798us       on 1.06ms       post 708us      diff 303us
align 67108864  pre 756us       on 997us        post 747us      diff 246us
align 33554432  pre 759us       on 1.04ms       post 751us      diff 282us
align 16777216  pre 758us       on 1.03ms       post 744us      diff 282us
align 8388608   pre 722us       on 962us        post 716us      diff 242us
align 4194304   pre 714us       on 956us        post 712us      diff 243us
align 2097152   pre 723us       on 835us        post 719us      diff 114us
align 1048576   pre 719us       on 794us        post 727us      diff 70.6us
align 524288    pre 721us       on 803us        post 730us      diff 77us
align 262144    pre 719us       on 795us        post 728us      diff 71.3us
align 131072    pre 717us       on 790us        post 728us      diff 67.6us
align 65536     pre 720us       on 797us        post 729us      diff 72.7us
align 32768     pre 718us       on 799us        post 727us      diff 76.4us
align 16384     pre 727us       on 790us        post 716us      diff 68.4us
align 8192      pre 722us       on 749us        post 724us      diff 26us
align 4096      pre 720us       on 745us        post 719us      diff 25.7us
~ # 
~ # flashbench -a -b 4096 /dev/mmcblk0 
align 2147483648        pre 756us       on 943us        post 756us      diff 187us
align 1073741824        pre 846us       on 1.11ms       post 828us      diff 276us
align 536870912 pre 848us       on 1.05ms       post 802us      diff 228us
align 268435456 pre 803us       on 1.03ms       post 840us      diff 209us
align 134217728 pre 843us       on 1.08ms       post 759us      diff 280us
align 67108864  pre 806us       on 1.02ms       post 797us      diff 220us
align 33554432  pre 805us       on 1.06ms       post 810us      diff 253us
align 16777216  pre 813us       on 1.05ms       post 800us      diff 246us
align 8388608   pre 764us       on 991us        post 771us      diff 224us
align 4194304   pre 773us       on 985us        post 763us      diff 217us
align 2097152   pre 762us       on 857us        post 768us      diff 91.9us
align 1048576   pre 783us       on 827us        post 781us      diff 44.6us
align 524288    pre 766us       on 824us        post 787us      diff 47.6us
align 262144    pre 775us       on 819us        post 783us      diff 40.1us
align 131072    pre 769us       on 813us        post 784us      diff 37.1us
align 65536     pre 774us       on 822us        post 781us      diff 44.5us
align 32768     pre 771us       on 825us        post 781us      diff 48.6us
align 16384     pre 778us       on 816us        post 779us      diff 37.5us
align 8192      pre 773us       on 770us        post 773us      diff -2926ns
~ # 
~ # flashbench -a -b 8192 /dev/mmcblk0 
align 2147483648        pre 861us       on 1.06ms       post 859us      diff 195us
align 1073741824        pre 956us       on 1.22ms       post 937us      diff 272us
align 536870912 pre 952us       on 1.17ms       post 911us      diff 235us
align 268435456 pre 905us       on 1.13ms       post 944us      diff 203us
align 134217728 pre 948us       on 1.19ms       post 870us      diff 279us
align 67108864  pre 912us       on 1.12ms       post 924us      diff 202us
align 33554432  pre 920us       on 1.16ms       post 917us      diff 244us
align 16777216  pre 908us       on 1.16ms       post 921us      diff 242us
align 8388608   pre 870us       on 1.09ms       post 878us      diff 216us
align 4194304   pre 872us       on 1.08ms       post 871us      diff 209us
align 2097152   pre 874us       on 951us        post 874us      diff 76.9us
align 1048576   pre 879us       on 927us        post 884us      diff 45.6us
align 524288    pre 873us       on 929us        post 896us      diff 44.7us
align 262144    pre 887us       on 931us        post 895us      diff 39.8us
align 131072    pre 882us       on 925us        post 887us      diff 40us
align 65536     pre 881us       on 936us        post 883us      diff 54.5us
align 32768     pre 884us       on 932us        post 884us      diff 48us
align 16384     pre 887us       on 926us        post 879us      diff 43.2us
~ # 
~ # flashbench -a -b 16384 /dev/mmcblk0 
align 2147483648        pre 1.05ms      on 1.24ms       post 1.09ms     diff 165us
align 1073741824        pre 1.15ms      on 1.42ms       post 1.13ms     diff 279us
align 536870912 pre 1.15ms      on 1.37ms       post 1.11ms     diff 235us
align 268435456 pre 1.1ms       on 1.32ms       post 1.15ms     diff 196us
align 134217728 pre 1.15ms      on 1.39ms       post 1.08ms     diff 277us
align 67108864  pre 1.11ms      on 1.33ms       post 1.11ms     diff 212us
align 33554432  pre 1.1ms       on 1.36ms       post 1.12ms     diff 254us
align 16777216  pre 1.1ms       on 1.36ms       post 1.12ms     diff 250us
align 8388608   pre 1.07ms      on 1.28ms       post 1.09ms     diff 201us
align 4194304   pre 1.08ms      on 1.27ms       post 1.07ms     diff 197us
align 2097152   pre 1.08ms      on 1.15ms       post 1.08ms     diff 72.7us
align 1048576   pre 1.1ms       on 1.14ms       post 1.09ms     diff 47.1us
align 524288    pre 1.08ms      on 1.13ms       post 1.1ms      diff 40.7us
align 262144    pre 1.09ms      on 1.14ms       post 1.1ms      diff 43.2us
align 131072    pre 1.09ms      on 1.14ms       post 1.1ms      diff 44.4us
align 65536     pre 1.09ms      on 1.13ms       post 1.09ms     diff 44.3us
align 32768     pre 1.09ms      on 1.14ms       post 1.09ms     diff 50us
~ # 
~ # flashbench -a -b 32768 /dev/mmcblk0 
align 2147483648        pre 1.56ms      on 1.64ms       post 1.59ms     diff 62.1us
align 1073741824        pre 1.65ms      on 1.82ms       post 1.58ms     diff 205us
align 536870912 pre 1.65ms      on 1.77ms       post 1.57ms     diff 163us
align 268435456 pre 1.59ms      on 1.71ms       post 1.6ms      diff 110us
align 134217728 pre 1.64ms      on 1.79ms       post 1.55ms     diff 193us
align 67108864  pre 1.6ms       on 1.72ms       post 1.58ms     diff 131us
align 33554432  pre 1.59ms      on 1.74ms       post 1.58ms     diff 154us
align 16777216  pre 1.6ms       on 1.76ms       post 1.58ms     diff 176us
align 8388608   pre 1.54ms      on 1.67ms       post 1.54ms     diff 124us
align 4194304   pre 1.54ms      on 1.67ms       post 1.53ms     diff 133us
align 2097152   pre 1.54ms      on 1.56ms       post 1.52ms     diff 26.9us
align 1048576   pre 1.57ms      on 1.56ms       post 1.55ms     diff 6.15us
align 524288    pre 1.55ms      on 1.56ms       post 1.57ms     diff 4.59us
align 262144    pre 1.55ms      on 1.57ms       post 1.56ms     diff 13.4us
align 131072    pre 1.55ms      on 1.56ms       post 1.57ms     diff 5.72us
align 65536     pre 1.54ms      on 1.56ms       post 1.55ms     diff 11.7us
~ # 

open-au

用于寻找allocation unit(au)的数目,open-au代表copy-on-write-then-erase能同时发生的个数,越多代表读写性能越好

what is copy-and-write-then-erase ?
if you want to change just one bit within an eraseblock the controller will often copy the entire eraseblock contents to another eraseblock but with your one bit change. The controller will then set the old eraseblock to be erased, possibly in the background.

flashbench软件会测试从-b到-e之间指定的文件块大小写到sd卡里面,然后测试不同的速度,通过–open-au-nr选项可以指定open allocation unit的个数,根据不同open allocation unit个数的测试情况,可以看出sd卡拥有多少个open allocation unit。

~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=1 /dev/mmcblk0 
4MiB    10.1M/s 
2MiB    6.16M/s 
1MiB    7.86M/s 
512KiB  16.7M/s 
256KiB  16M/s   
128KiB  14.8M/s 
64KiB   13M/s   
32KiB   10.9M/s 
16KiB   8.87M/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=2 /dev/mmcblk0 
4MiB    10.9M/s 
2MiB    16.8M/s 
1MiB    16.6M/s 
512KiB  16.6M/s 
256KiB  15.8M/s 
128KiB  14.7M/s 
64KiB   12.8M/s 
32KiB   10.8M/s 
16KiB   8.53M/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=8 /dev/mmcblk0 
4MiB    14.2M/s 
2MiB    16.8M/s 
1MiB    13.8M/s 
512KiB  16.6M/s 
256KiB  15.9M/s 
128KiB  14.7M/s 
64KiB   12.7M/s 
32KiB   10.7M/s 
16KiB   8.45M/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=9 /dev/mmcblk0 
4MiB    16.7M/s 
2MiB    7.2M/s  
1MiB    3.22M/s 
512KiB  1.44M/s 
256KiB  692K/s  
128KiB  344K/s  
64KiB   170K/s  
32KiB   84.9K/s 
16KiB   42.5K/s 

从上面看出来是在–open-au-nr=9时候的速度和前面比明显变慢了。所以–open-au-nr=8了。
为了更符合实际的情况,常常在测试的时候加上参数-r,表示随机写。

~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=1 -r /dev/mmcblk0 
4MiB    18.4M/s 
2MiB    3.61M/s 
1MiB    3.13M/s 
512KiB  3.13M/s 
256KiB  1.12M/s 
128KiB  576K/s  
64KiB   324K/s  
32KiB   157K/s  
16KiB   75.3K/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=2 -r /dev/mmcblk0 
4MiB    5.12M/s 
2MiB    16.6M/s 
1MiB    12M/s   
512KiB  4.51M/s 
256KiB  1.12M/s 
128KiB  591K/s  
64KiB   323K/s  
32KiB   156K/s  
16KiB   74.8K/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=8 -r /dev/mmcblk0 
4MiB    16.8M/s 
2MiB    13.8M/s 
1MiB    12M/s   
512KiB  4.29M/s 
256KiB  1.09M/s 
128KiB  592K/s  
64KiB   322K/s  
32KiB   156K/s  
16KiB   74.6K/s 
~ # 
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=9 -r /dev/mmcblk0 
4MiB    14.4M/s 
2MiB    5.26M/s 
1MiB    3.21M/s 
512KiB  1.44M/s 
256KiB  692K/s  
128KiB  344K/s  
64KiB   170K/s  
32KiB   84.9K/s 
16KiB   42.4K/s 

fat

we can check if the first few eraseblocks have any special ability. Some cards will provide for the first few eraseblocks to be backed by SLC flash instead of MLC, or otherwise improve the performance of these special eraseblocks. This is important when using the card with the FAT filesystem as all the metadata is stored in the beginning of the disk and will get the most wear and small writes.

~ # flashbench /dev/mmcblk0 -f -e 4194304
4MiB    16.7M/s  32.2M/s  16.7M/s  16.8M/s  16.7M/s  16.7M/s  
2MiB    16.8M/s  29.7M/s  16.6M/s  16.8M/s  16.8M/s  16.8M/s  
1MiB    16.8M/s  29.9M/s  16.7M/s  16.8M/s  16.8M/s  16.7M/s  
512KiB  16.6M/s  29.7M/s  16.5M/s  16.8M/s  16.7M/s  16.7M/s  
256KiB  16.1M/s  25.8M/s  16M/s    16.1M/s  16M/s    16.1M/s  
128KiB  14.7M/s  20M/s    14.6M/s  14.9M/s  14.8M/s  14.9M/s  
64KiB   13M/s    20.5M/s  12.9M/s  13M/s    13M/s    12.9M/s  
32KiB   11M/s    15.2M/s  10.8M/s  11M/s    10.9M/s  10.9M/s  
16KiB   8.89M/s  9.97M/s  8.92M/s  8.95M/s  8.97M/s  8.96M/s  

从上面可以看出来在第二列的速度明显比周围的速度快很多,可以作为fat分区会提高读写效率。


scatter

flashbench --scatter --scatter-order=N --scatter-span=N -b blocksize /dev/mmcblk0 -o /tmp/scatter_result
it is mainly a way to detect the block size if the -a test gives no conclusive result
–scatter
–scatter-order=M 定义scatter测试读取的区域,那么读取的区域的总大小为blocksize * 2^M (-b指定blocksize大小)
–scatter-span=N 一次读取的block的数量,那么一次读取的大小为blocksize * 2^N
-b 指定blocksize大小
-o 指定测试结果的输出文件
然后使用工具gnuplot将scatter_result绘制成二维图像,gnuplot -p -e ‘plot “scatter_result”’。

下面是我在自己这边的平台上测试的数据:
flashbench --scatter --scatter-order=11 --scatter-span=1 -b 16384 /dev/mmcblk0 -o /tmp/scatter_result
这里写图片描述
flashbench --scatter --scatter-order=11 --scatter-span=2 -b 16384 /dev/mmcblk0 -o /tmp/scatter_result
这里写图片描述
横轴为32M,因为这里的–scatter-order=11,所以整个scatter测试覆盖的区域是16384 * 2^11=32M,是sd卡最开头的32M
纵轴代表一次读取–scatter-span指定这么多个blocksize所要的时间,单位是ms
图中的每一个”+”都是一个测试结果,每次测试往后偏移blocksize大小,然后测试读取–scatter-span指定个数的blocksize大小的文件的时间,就得到一个”+”,横坐标代表偏移的位置,纵坐标代表读取–scatter-span指定个数的blocksize大小的文件的时间。


interval

这里写图片描述
用于分析从读取512 bytes到读取512 * 2^(N-1) bytes之间的速度与大小的关系,并将这些值做线性回归分析。
–interval-order=N 指定依次测试从512 bytes到512 * 2^N-1 bytes大小的blocksize
-c 指定测试的次数,这样每次测试的时候依次往后偏移9 * blocksize大小,指定次数测试完后会计算平均值,最大值,最小值等。

~ # flashbench -i --interval-order=13 -b 16384 /dev/mmcblk0 
512 bytes: min 408us avg 493us max 924us: 1.25414 MB/s
1024 bytes: min 439us avg 462us max 508us: 2.33469 MB/s
2048 bytes: min 466us avg 488us max 510us: 4.39144 MB/s
4096 bytes: min 535us avg 550us max 571us: 7.66278 MB/s
8192 bytes: min 633us avg 687us max 744us: 12.9385 MB/s
16384 bytes: min 906us avg 941us max 1.02ms: 18.0824 MB/s
32768 bytes: min 1.34ms avg 1.43ms max 1.54ms: 24.4092 MB/s
65536 bytes: min 2.2ms avg 2.27ms max 2.51ms: 29.8218 MB/s
131072 bytes: min 3.34ms avg 3.7ms max 4.32ms: 39.1904 MB/s
262144 bytes: min 6.22ms avg 7.17ms max 8.06ms: 42.1701 MB/s
524288 bytes: min 11.8ms avg 15ms max 21.4ms: 44.5035 MB/s
1048576 bytes: min 27.7ms avg 30.5ms max 43.6ms: 37.871 MB/s
2097152 bytes: min 55ms avg 61.5ms max 86.6ms: 38.1285 MB/s
38.4339 MB/s, 62.2us access time
bytes 512, time 408248 overhead 332736
bytes 1024, time 438602 overhead 349769
bytes 2048, time 466362 overhead 350886
bytes 4096, time 534532 overhead 365769
bytes 8192, time 633148 overhead 357813
bytes 16384, time 906074 overhead 417593
bytes 32768, time 1342443 overhead 427672
bytes 65536, time 2197584 overhead 430232
bytes 131072, time 3344490 overhead -128025
bytes 262144, time 6216344 overhead -666496
bytes 524288, time 11780814 overhead -1.92268e+06
bytes 1048576, time 27688070 overhead 343282
bytes 2097152, time 55002223 overhead 374836

program

~ # flashbench -p /dev/mmcblk0
2MiB    7.62M/s  10.3M/s  12.1M/s  35.4M/s  6.02M/s  7.71M/s  7.6M/s   38M/s    
1MiB    11.4M/s  13.3M/s  13.3M/s  38.2M/s  6.21M/s  7.68M/s  7.66M/s  37.5M/s  
512KiB  16.6M/s  16.7M/s  16.7M/s  37.9M/s  7.63M/s  4.83M/s  5.2M/s   37M/s    
256KiB  15.3M/s  16.1M/s  16.1M/s  36.3M/s  2.68M/s  1.22M/s  1.16M/s  36.6M/s  
128KiB  14.4M/s  14.9M/s  14.8M/s  34.4M/s  2.17M/s  1.67M/s  1.68M/s  33.8M/s  
64KiB   12.9M/s  13M/s    13.1M/s  30.3M/s  1.27M/s  1.04M/s  1.05M/s  29.8M/s  
32KiB   11M/s    11M/s    10.9M/s  24.5M/s  476K/s   441K/s   438K/s   24.1M/s  
16KiB   9.93M/s  9.92M/s  9.96M/s  18M/s    273K/s   253K/s   247K/s   17.8M/s  
8KiB    3.74M/s  3.75M/s  3.75M/s  11.6M/s  3.8M/s   3.82M/s  3.82M/s  11.5M/s  
4KiB    1.52M/s  1.6M/s   1.6M/s   6.8M/s   1.92M/s  1.93M/s  1.92M/s  6.73M/s  
2KiB    604K/s   683K/s   683K/s   3.71M/s  980K/s   979K/s   979K/s   3.67M/s  
1KiB    246K/s   273K/s   273K/s   1.94M/s  470K/s   469K/s   472K/s   1.91M/s  
512B    264K/s   286K/s   286K/s   1.04M/s  243K/s   243K/s   244K/s   1.04M/s  

第一列代表每次读写文件的大小,测试的原理是写4M的文件,对于2M的大小,测试两次,对于1M的大小,测试4次,依次类推。
后面的几列依次是linear write zeros, linear write ones, linear write 0x5a, linear read,
random write zeros, random write ones, random write 0x5a, random read的速度

补充一下:
线性读写:每次读写完N字节后,偏移也加N字节,然后从偏移处继续读写,这样写指针在进行新的一次读写的时候不需要移动。
随机位置读写:写完上一笔数据后,重新移动写指针到别的某个位置,然后在进行一次新的读写。
随机内容读写:写的内容是随机的内容,这个对读写速度的测试不影响。
随机位置读写由于要重新移动写指针,而线性读写不需要移动写指针,所以随机位置的读写速度明显要比线性读写的速度慢。


通过dd测试sd卡读写速度

使用dd命令来测试sd卡读写速度,测试内容如下:
这里写图片描述
从图中可以看出来,在输入分别为/dev/zero,/dev/random, /dev/urandom,写卡的速度是有很大差别的,与上面使用flashbench测试随机写1M文件的速度25.2M/s相比小很多,看起来dd测试速度的时候将读取输入的时间也算在内了,所以速度相对来说小很多,而且在读取/dev/zero,/dev/random, /dev/urandom这3个不同的输入的时间的差别也相差很大。
所以,dd测试速度的时候将读取输入的时间也算在内了,使用dd测试sd卡速度是不够准确的。


通过dd测试sd卡真实容量

Create a file with the required capacity, filled with random data. We’re writing blocks of 1024 bytes, so adjust the count to the capacity required (16GB in my case).
dd if=/dev/urandom of=rnd_init_data bs=1024 count=16000000

Now, we write the data to the SD card.

$ dd if=rnd_init_data of=/dev/sdb bs=1024 count=16000000
15558145+0 records in
15558144+0 records out
15931539456 bytes (16 GB) copied, 536.286 s, 29.7 MB/s

You can see, we didn’t manage to write all the bytes to the card. This is expected, as we don’t know the capacity of the card down to the last byte. As long as the capacity reported by dd (16 GB) is close to the expected result, we’re happy.

Now, we copy the bytes written to a new file, which we use for later comparison. Notice here the count, which we adapted to the bytes written to the card (15931539456 / 1024 = 15558144). I am sure this can be done easier using tools like truncate, but I didn’t want to start messing with programs that I don’t know by heart.

$ dd if=rnd_init_data of=rnd_written_data bs=1024 count=15558144
$ rm -f rnd_init_data

Read back the data from the card:
$ dd if=/dev/sdb of=rnd_read_data bs=1024 count=15558144
Finally, we’re comparing the two data files:

$ md5sum rnd*
dfed784abed6662926eb01f7fb5359ca  rnd_written_data
dfed784abed6662926eb01f7fb5359ca  rnd_read_data

通过fio测试sd卡读写速度

使用fio命令测试sd卡读写速度,测试命令

读:fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=read
随机读:fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=randread
写:fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=write
随机写:fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=randwrite

测试的结果与使用flashbench测试结果对比如下:
这里写图片描述
fio所测试的速度相对flashbench所测试的速度稍微慢一点,在合理的偏差范围内,但基本的速度随着读写文件的大小变化情况是一致的。


参考文章

  1. Flashbenching
  2. Flash memory card design
  3. Optimizing Linux with cheap flash drives
  • 2
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

luckywang1103

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值