[prev in list] [next in list] [prev in thread] [next in thread]
List: linaro-flashbench-results
Subject: Re: [Flashbench] Sandisk Extreme 16GB MicroSDHC - unclear results
From: Marcel Partap <mpartap () gmx ! net>
Date: 2014-08-19 15:12:39
Message-ID: 53F36967.1040909 () gmx ! net
[Download RAW message or body]
On 11/08/14 13:44, Andrew Bradford wrote:
> On 08/06/2014 02:50 PM, Marcel Partap wrote:
>>> Finding the erase block size in order to align the partitions is more
>>> important than the mkfs parameters and will make a much larger impact on
>>> performance than setting ideal stride and stripe.
>> [...]
>>
>>> Likely the card does not have an erase block size smaller than 2 MiB due
>>> to the amount of flash in it, so 128 kiB is probably not the correct
>>> erase block size. Most larger sized cards have 2, 4 or 8 MiB erase
>>> blocks these days.
>>
>> Why then would there not be a step in timing difference at f.e. 2MiB?
>
> SanDisk controllers are known to have fancy tricks which result in
> better performance under certain loads, hiding the actual erase block
> size may be a side effect. I don't really know the root cause but I
> have seen this kind of behavior before.
>
>>> It's probably easier for those who read this list to see raw output of
>>> flashbench rather than looking at csv files or plots in order to assist
>>> with interpreting your results.
>>
>> Here it is.
>>> flashbench --count=1000 -a /dev/sdb --blocksize=$((1*1024))
>>> align 4294967296 pre 611 µs on 799 µs post 615 µs diff 186 µs
>>> align 2147483648 pre 615 µs on 792 µs post 619 µs diff 175 µs
>>> align 1073741824 pre 608 µs on 812 µs post 613 µs diff 201 µs
>>> align 536870912 pre 615 µs on 771 µs post 619 µs diff 153 µs
>>> align 268435456 pre 607 µs on 774 µs post 612 µs diff 164 µs
>>> align 134217728 pre 614 µs on 800 µs post 617 µs diff 185 µs
>>> align 67108864 pre 614 µs on 799 µs post 618 µs diff 183 µs
>>> align 33554432 pre 612 µs on 783 µs post 614 µs diff 171 µs
>>> align 16777216 pre 607 µs on 748 µs post 613 µs diff 138 µs
>>> align 8388608 pre 605 µs on 742 µs post 605 µs diff 137 µs
>>> align 4194304 pre 603 µs on 749 µs post 608 µs diff 143 µs
>>> align 2097152 pre 603 µs on 750 µs post 607 µs diff 146 µs
>>> align 1048576 pre 601 µs on 741 µs post 603 µs diff 139 µs
>>> align 524288 pre 603 µs on 767 µs post 615 µs diff 158 µs
>>> align 262144 pre 597 µs on 747 µs post 604 µs diff 146 µs
>>> align 131072 pre 606 µs on 751 µs post 611 µs diff 143 µs
>>> align 65536 pre 603 µs on 705 µs post 609 µs diff 99.1 µs
>>> align 32768 pre 606 µs on 694 µs post 595 µs diff 93.6 µs
>>> align 16384 pre 601 µs on 703 µs post 604 µs diff 100 µs
>>> align 8192 pre 614 µs on 613 µs post 611 µs diff 351ns
>>> align 4096 pre 613 µs on 616 µs post 608 µs diff 5.19 µs
>>> align 2048 pre 612 µs on 613 µs post 614 µs diff 276ns
>>
>> What would you make from that? The drop-off definitely is @128K...
>
> Could be caching or intermediate SLC flash or the page size.
>
> Try running with '--blocksize=$(3*1024)' and see if any noticeable
> changes happen. Some SanDisk cards look like 1.5 MiB erase blocks and
> this can be exposed with the 3072 blocksize.
> align 3221225472 pre 714 µs on 829 µs post 710 µs diff 117 µs
> align 1610612736 pre 712 µs on 834 µs post 717 µs diff 120 µs
> align 805306368 pre 713 µs on 823 µs post 703 µs diff 115 µs
> align 402653184 pre 728 µs on 839 µs post 724 µs diff 113 µs
> align 201326592 pre 722 µs on 846 µs post 728 µs diff 120 µs
> align 100663296 pre 721 µs on 838 µs post 721 µs diff 118 µs
> align 50331648 pre 723 µs on 845 µs post 729 µs diff 119 µs
> align 25165824 pre 711 µs on 843 µs post 731 µs diff 122 µs
> align 12582912 pre 716 µs on 828 µs post 727 µs diff 107 µs
> align 6291456 pre 717 µs on 841 µs post 732 µs diff 117 µs
> align 3145728 pre 720 µs on 839 µs post 721 µs diff 118 µs
> align 1572864 pre 717 µs on 840 µs post 721 µs diff 121 µs
> align 786432 pre 726 µs on 849 µs post 703 µs diff 134 µs
> align 393216 pre 720 µs on 845 µs post 724 µs diff 122 µs
> align 196608 pre 729 µs on 742 µs post 721 µs diff 16.7 µs
> align 98304 pre 724 µs on 739 µs post 729 µs diff 12.8 µs
> align 49152 pre 722 µs on 715 µs post 725 µs diff -8583ns
> align 24576 pre 711 µs on 713 µs post 713 µs diff 977ns
> align 12288 pre 733 µs on 726 µs post 737 µs diff -9350ns
> align 6144 pre 725 µs on 730 µs post 739 µs diff -1197ns
> Alternatively, you can do write testing and move the offset to span
> where you think the erase block edges are and see if performance drops
> off when crossing the erase block boundary. This is a better indicator
> but takes much longer to do.
I did something in that line, which indeed took a long time to do... I
created a FAT32 partition at sector 63 (unaligned), 1MiB, 2MiB, 3MiB and
24MiB and ran
# iozone -a -i 0 -i 1 -i 2 -g 32m -I
# -a: automatic mode
# -i 0 -i 1 -i 2: test 0=write/rewrite, 1=read/re-read,
2=random-read/write
# -g 32m: maximum file size 32MB
# -I: DIRECT IO (bypass cache)
on each, than fed them into the "iozone-results-comparator" .. resulting
graphs is attached and leaves me inconclusive. Huh?
#Regards!MPartap
["iozone-16gb-sdcard-alignment-comparison.tar.xz" (application/x-xz)]
_______________________________________________
Flashbench-results mailing list
Flashbench-results@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/flashbench-results
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic