Hi,
I have following cheaply bought SD-Card from Ebay:
Samsung 32 GB
MB-SSBGA
MBSSBGVEOBGA-SH
D 13CG5000 1 3 6
$:/sys/block/mmcblk0/device# head
/sys/block/mmcblk0/device/{c*,scr,*rev,*id,serial,*size}
==> /sys/block/mmcblk0/device/cid <==
1b534d3030303030107677b02300c100
==> /sys/block/mmcblk0/device/csd <==
400e00325b590000e9e57f800a404000
==> /sys/block/mmcblk0/device/scr <==
02b5800200000000
==> /sys/block/mmcblk0/device/fwrev <==
0x0
==> /sys/block/mmcblk0/device/hwrev <==
0x1
==> /sys/block/mmcblk0/device/cid <==
1b534d3030303030107677b02300c100
==> /sys/block/mmcblk0/device/manfid <==
0x00001b
==> /sys/block/mmcblk0/device/oemid <==
0x534d
==> /sys/block/mmcblk0/device/serial <==
0x7677b023
==> /sys/block/mmcblk0/device/erase_size <==
512
==> /sys/block/mmcblk0/device/preferred_erase_size <==
4194304
and here is the first Benchmark which is for me hard to interprete:
root@ThinkPad-T400:~/flashbench/flashbench# ./flashbench -a /dev/mmcblk0
--blocksize 1024 --count=100
align 8589934592 pre 208µs on 221µs post 206µs diff 14.3µs
align 4294967296 pre 207µs on 223µs post 208µs diff 15.1µs
align 2147483648 pre 205µs on 219µs post 207µs diff 13µs
align 1073741824 pre 257µs on 305µs post 241µs diff 56.7µs
align 536870912 pre 225µs on 261µs post 225µs diff 36µs
align 268435456 pre 294µs on 387µs post 281µs diff 100µs
align 134217728 pre 239µs on 285µs post 234µs diff 48.1µs
align 67108864 pre 222µs on 267µs post 220µs diff 46.6µs
align 33554432 pre 211µs on 257µs post 218µs diff 41.8µs
align 16777216 pre 231µs on 296µs post 237µs diff 61.8µs
align 8388608 pre 224µs on 260µs post 225µs diff 36.2µs
align 4194304 pre 222µs on 259µs post 227µs diff 34.4µs
align 2097152 pre 230µs on 260µs post 213µs diff 38.6µs
align 1048576 pre 218µs on 254µs post 223µs diff 33.8µs
align 524288 pre 234µs on 266µs post 216µs diff 40.7µs
align 262144 pre 224µs on 258µs post 224µs diff 33.3µs
align 131072 pre 228µs on 257µs post 210µs diff 37.8µs
align 65536 pre 212µs on 248µs post 216µs diff 33.8µs
align 32768 pre 223µs on 253µs post 205µs diff 38.3µs
align 16384 pre 239µs on 258µs post 234µs diff 21.3µs
align 8192 pre 233µs on 233µs post 233µs diff 424ns
align 4096 pre 234µs on 240µs post 234µs diff 5.88µs
align 2048 pre 233µs on 234µs post 234µs diff 584ns
in other outputs there are more or less only two steps (at eraseblock size
and blocksize) and they are differently ordered. The Debug FS says erase
block should be 4 MB but from this Benchmark I would suggest something like
2GB?!? Or is it 128MB ? Blocksize is 16KB i would suggest but I could be
wrong ... could you help me ? I will give the other results if the block
sizes are more clear to me...
Hi,
I'm having troubles at the first step: determining the erase block
size. The strange results are below.
The original FAT layout was not saved when the drive was purchased.
# lsusb
Bus 004 Device 002: ID 125f:c82a A-DATA Technology Co., Ltd.
# fdisk -l /dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1061309422330015-0\:0
Disk /dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1061309422330015-0:0:
7873 MB, 7873757184 bytes
180 heads, 14 sectors/track, 6102 cylinders, total 15378432 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: 0xf65985aa
Device Boot
Start End Blocks Id System
/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1061309422330015-0:0-part1
2048 15378431 7688192 83 Linux
# for i in 1 2 4 8 16; do echo -e "\n\nbs=$[$i*1024]"; flashbench -a
/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1061309422330015-0\:0
--blocksize=$[$i*1024]; done
bs=1024
align 2147483648 pre 829µs on 815µs post 836µs
diff -17473n
align 1073741824 pre 846µs on 796µs post 853µs
diff -53379n
align 536870912 pre 744µs on 781µs post 834µs diff -8238ns
align 268435456 pre 827µs on 798µs post 831µs diff -31049n
align 134217728 pre 758µs on 763µs post 763µs diff 2.71µs
align 67108864 pre 789µs on 779µs post 815µs diff -22737n
align 33554432 pre 773µs on 747µs post 779µs diff -29372n
align 16777216 pre 695µs on 773µs post 816µs diff 16.8µs
align 8388608 pre 688µs on 728µs post 691µs diff 39µs
align 4194304 pre 733µs on 779µs post 815µs diff 4.47µs
align 2097152 pre 742µs on 761µs post 759µs diff 10.8µs
align 1048576 pre 811µs on 793µs post 817µs diff -21380n
align 524288 pre 799µs on 794µs post 816µs diff -13187n
align 262144 pre 756µs on 795µs post 800µs diff 17µs
align 131072 pre 737µs on 685µs post 744µs diff -55710n
align 65536 pre 741µs on 747µs post 747µs diff 3.18µs
align 32768 pre 798µs on 780µs post 799µs diff -18178n
align 16384 pre 732µs on 779µs post 796µs diff 15.1µs
align 8192 pre 740µs on 776µs post 799µs diff 7.01µs
align 4096 pre 952µs on 758µs post 799µs diff -117830
align 2048 pre 738µs on 774µs post 798µs diff 6.04µs
bs=2048
align 2147483648 pre 853µs on 848µs post 869µs
diff -12804n
align 1073741824 pre 861µs on 869µs post 869µs
diff 3.88µs
align 536870912 pre 833µs on 834µs post 835µs diff -193ns
align 268435456 pre 877µs on 907µs post 900µs diff 18.4µs
align 134217728 pre 842µs on 851µs post 870µs diff -5455ns
align 67108864 pre 828µs on 799µs post 833µs diff -31688n
align 33554432 pre 767µs on 827µs post 832µs diff 26.9µs
align 16777216 pre 758µs on 776µs post 762µs diff 16.2µs
align 8388608 pre 713µs on 714µs post 712µs diff 868ns
align 4194304 pre 857µs on 887µs post 866µs diff 25.9µs
align 2097152 pre 837µs on 867µs post 872µs diff 12.7µs
align 1048576 pre 847µs on 834µs post 847µs diff -13895n
align 524288 pre 865µs on 882µs post 866µs diff 16.4µs
align 262144 pre 864µs on 849µs post 868µs diff -17470n
align 131072 pre 795µs on 799µs post 799µs diff 1.98µs
align 65536 pre 868µs on 868µs post 867µs diff 205ns
align 32768 pre 866µs on 867µs post 868µs diff -623ns
align 16384 pre 859µs on 853µs post 871µs diff -11754n
align 8192 pre 859µs on 869µs post 849µs diff 15µs
align 4096 pre 978µs on 980µs post 829µs diff 76.4µs
bs=4096
align 2147483648 pre 905µs on 908µs post 1.05ms
diff -70516n
align 1073741824 pre 997µs on 979µs post 1.11ms
diff -72729n
align 536870912 pre 961µs on 978µs post 1.1ms diff -51399n
align 268435456 pre 965µs on 973µs post 1.07ms diff -42441n
align 134217728 pre 890µs on 891µs post 1.03ms diff -70698n
align 67108864 pre 855µs on 838µs post 1.02ms diff -97971n
align 33554432 pre 853µs on 870µs post 1.05ms diff -80043n
align 16777216 pre 832µs on 832µs post 1.03ms diff -98061n
align 8388608 pre 842µs on 843µs post 1.03ms diff -92877n
align 4194304 pre 933µs on 960µs post 1.08ms diff -46878n
align 2097152 pre 924µs on 926µs post 1.03ms diff -51066n
align 1048576 pre 948µs on 925µs post 1.07ms diff -82986n
align 524288 pre 970µs on 981µs post 1.1ms diff -55840n
align 262144 pre 985µs on 954µs post 1.12ms diff -97010n
align 131072 pre 933µs on 944µs post 1.08ms diff -60718n
align 65536 pre 970µs on 956µs post 1.03ms diff -46152n
align 32768 pre 963µs on 943µs post 1.11ms diff -91246n
align 16384 pre 914µs on 924µs post 1.07ms diff -67228n
align 8192 pre 923µs on 924µs post 1.09ms diff -80328n
bs=8192
align 2147483648 pre 1.66ms on 1.62ms post 1.64ms
diff -29621n
align 1073741824 pre 1.65ms on 1.64ms post 1.68ms
diff -22022n
align 536870912 pre 1.62ms on 1.62ms post 1.62ms diff 662ns
align 268435456 pre 1.62ms on 1.6ms post 1.62ms diff -17675n
align 134217728 pre 1.64ms on 1.61ms post 1.64ms diff -31935n
align 67108864 pre 1.68ms on 1.67ms post 1.67ms diff -3326ns
align 33554432 pre 1.73ms on 1.74ms post 1.74ms diff 9.42µs
align 16777216 pre 1.66ms on 1.64ms post 1.64ms diff -7797ns
align 8388608 pre 1.65ms on 1.66ms post 1.65ms diff 8.27µs
align 4194304 pre 1.63ms on 1.65ms post 1.65ms diff 10.3µs
align 2097152 pre 1.62ms on 1.64ms post 1.64ms diff 6.62µs
align 1048576 pre 1.66ms on 1.66ms post 1.65ms diff 2.68µs
align 524288 pre 1.66ms on 1.64ms post 1.64ms diff -6934ns
align 262144 pre 1.65ms on 1.66ms post 1.66ms diff 197ns
align 131072 pre 1.64ms on 1.64ms post 1.64ms diff 1.64µs
align 65536 pre 1.65ms on 1.62ms post 1.62ms diff -12165n
align 32768 pre 1.66ms on 1.66ms post 1.67ms diff -9644ns
align 16384 pre 1.62ms on 1.62ms post 1.64ms diff -9352ns
bs=16384
align 2147483648 pre 2.39ms on 2.35ms post 2.33ms
diff -7216ns
align 1073741824 pre 2.46ms on 2.44ms post 2.43ms
diff 341ns
align 536870912 pre 2.28ms on 2.28ms post 2.28ms diff -1850ns
align 268435456 pre 2.32ms on 2.28ms post 2.3ms diff -29446n
align 134217728 pre 2.3ms on 2.32ms post 2.32ms diff 7.53µs
align 67108864 pre 2.32ms on 2.31ms post 2.3ms diff 2.12µs
align 33554432 pre 2.38ms on 2.41ms post 2.43ms diff 4µs
align 16777216 pre 2.32ms on 2.28ms post 2.27ms diff -7553ns
align 8388608 pre 2.28ms on 2.28ms post 2.29ms diff -6386ns
align 4194304 pre 2.28ms on 2.28ms post 2.28ms diff -1055ns
align 2097152 pre 2.28ms on 2.26ms post 2.28ms diff -18798n
align 1048576 pre 2.28ms on 2.28ms post 2.26ms diff 9.31µs
align 524288 pre 2.33ms on 2.32ms post 2.32ms diff -4279ns
align 262144 pre 2.29ms on 2.28ms post 2.25ms diff 8.77µs
align 131072 pre 2.3ms on 2.26ms post 2.3ms diff -35064n
align 65536 pre 2.31ms on 2.27ms post 2.28ms diff -33000n
align 32768 pre 2.3ms on 2.31ms post 2.34ms diff -730ns
# flashbench -a
/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1061309422330015-0\:0
--blocksize=$[10*1024]
align 1342177280 pre 1.66ms on 2.14ms post 1.69ms
diff 465µs
align 671088640 pre 1.66ms on 2.16ms post 1.66ms diff 499µs
align 335544320 pre 1.69ms on 2.19ms post 1.71ms diff 493µs
align 167772160 pre 1.76ms on 2.26ms post 1.75ms diff 510µs
align 83886080 pre 1.62ms on 2.09ms post 1.67ms diff 447µs
align 41943040 pre 1.8ms on 2.33ms post 1.76ms diff 551µs
align 20971520 pre 1.62ms on 2.12ms post 1.64ms diff 490µs
align 10485760 pre 1.64ms on 2.1ms post 1.65ms diff 455µs
align 5242880 pre 1.62ms on 2.08ms post 1.68ms diff 432µs
align 2621440 pre 1.65ms on 2.12ms post 1.68ms diff 456µs
align 1310720 pre 1.6ms on 2.03ms post 1.55ms diff 450µs
align 655360 pre 1.57ms on 2.03ms post 1.62ms diff 437µs
align 327680 pre 1.66ms on 2.08ms post 1.64ms diff 435µs
align 163840 pre 1.63ms on 2.06ms post 1.62ms diff 436µs
align 81920 pre 1.64ms on 2.08ms post 1.64ms diff 447µs
align 40960 pre 1.66ms on 2.19ms post 1.73ms diff 499µs
align 20480 pre 2.07ms on 1.64ms post 1.66ms diff -226664
Greetings,
My name is Luka from the Electronic Recycling Association (www.era.ca). In
hope you might be able to help us, I would like to tell you a little bit
about our charity work.
This is what we do: we are a non-profit organization dedicated in reducing
electronic waste through the reuse and recycling of unwanted computers. We
collect all kinds of IT and electronic equipment (computers, laptops,
printers, telephones etc). Then we refurbish it and donate to various
charities and non-profit organizations. That makes us different from any
other recycler, we want to add value to your company by donating! ERA`s
donations are followed by various media, so it can also help to improve your
company`s social responsibility profile.
This is what we can do for you:
- Pick up all of your old IT & electronic equipment you don`t need any more
at your site,
- Remove all of your company`s data from computers according to military
standards (free hard-drive wiping services plus data removal certificate),
- Refurbish your donated items and donate them to local charities in need in
your behalf.
- Recycle locally all of the equipment that cannot be reused.
With your help we can not only achieve our mission of reducing the negative
impact of electronic waste on our environment, but also ensure that your
unwanted computer equipment is donated to a worthy charity or non-profit
organization. These are the current charities we are trying to help, and the
list is, unfortunately, increasing: http://era.ca/index.php?page=charities.
Please contact me directly on 604 756 1930 if you have any electronic
equipment you would like to donate at this time or if you need any further
information about our services. We have offices and warehouses all across
Canada. I am looking forward to your response!
Thank you for your time and have a great day!
Sincerely,
Luka Belik
Donations Coordinator
Electronic Recycling Association
* luka(a)era.ca
* 604 756 1930
* www.era.ca
* 1 403 262 4488 | 1 604 215 4483 | 1 780 455 2088 | 1 877 939 2783
This is to let you know that the migration of lists.linaro.org has been
successfully completed.
As per the email I sent on Wednesday, it may take some time for the new
address of the server to be seen by your computer. You can check this by
trying to connect to the web site:
http://lists.linaro.org/
If you are able to connect and you do not get an error, this means you are
connecting to the new server and you can send email to the lists.
If you experience any problems after the weekend and you find that you
still cannot connect to the server, please reply to this email to let us
know.
Regards
Philip
IT Services Manager
Linaro
Hello
You are receiving this email because you are subscribed to one or more
mailing lists provided by the lists.linaro.org server.
IT Services are announcing planned maintenance for this server scheduled
for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work
is to move the service to another server. There will be some disruption
during this maintenance.
In order to ensure that you do not accidentally try to use the service
while it is being moved, the current server will be shut down at 2pm.
A further email will be sent on Friday afternoon to confirm that the
migration of the service is completed. However, due to the way servers are
found, it may take a while before your computer is able to connect to the
relocated service.
After the old server has been shut down, email sent to any of the lists
will be queued, but it is possible that the sending server will still
trying to deliver the email to the old server rather than the new one when
it is started.
It is therefore *strongly* recommended that you do not send any email to an
@lists.linaro.org email address until you can connect to the new service,
which you will be able to test by trying to use a web browser to connect to
http://lists.linaro.org after you receive the email confirming that the
migration has been completed. Since the old service will be shut down, if
you are able to connect, you can be sure you have connected to the new
service.
If by Monday you are still unable to connect to the service or you are not
able to send email to an @lists.linaro.org email address, please send an
email to its(a)linaro.org.
Thank you.
Regards
Philip
IT Services Manager
Linaro
Good Afternoon,
My name is Alan Briggs, I am responsible for all English speaking
markets at teliad, an international service provider in the field of
Search Engine Optimization (SEO).
I was just doing some research online for a current project I'm working
on and found your site lists.linaro.org. This seems like a good fit, as
it shows some great SEO factors. I figured I'd go ahead and use the
contact details provided on the webpage and drop you a quick line.
At this point, we'd be very interested in exploring the marketing
possibilities of your site - especially when it comes to integrating
text links (pure html backlinks).
Should this be of interest, I would certainly be happy to explain
further. Don't hesitate to give me a call or shoot me an email anytime!
Thanks & have a great day!
Best regards,
Alan Briggs
------------------------------------------------------------------------
teliad Internetmarketing GmbH |
Kreuznacher Str. 62 |
70372 Stuttgart | Tel. +49 (0)711 231 971 26
Germany | http://www.teliad.com
HRB 720138 Stuttgart Court of First Instance
CEO: Andreas Armbruster
------------------------------------------------------------------------
DISCLAIMER: The information contained in this e-mail may be confidential
and/or protected by law. If you are not the intended addressee(s) or
have received this message in error, please notify the sender
immediately and delete it from your system. Any unauthorized use,
distribution, copying or modification of this message and its
attachments is strictly prohibited.
To ensure delivery of these Emails to your inbox, please add sales(a)gk-ing.com to your email address book.
Dear :
How are you?Xmas season recommend you our new arrival DVR android gps tablet.
1)7 inch 800*480 Solution.
2)300M Dailyroads voyager DVR camera on the back,300K Pixels CMOS on fron
3)Android 4.0 Operation system
4)512MB Ram,8GB flash
5)WIFI 802.11 a/b/g/n
6)Map:Google map ,Igo,navitel etc.
Sample and small order available for you test before mass order.We also have many other models for your choice.For details pls visit http://www.gk-ing.com/products.html
Waiting for your any feedback ,thank you!
Best Regards
Cngking
G&K.Ing "We make miracle" ?
Add:Rm 703.KingLihua Commercial Building,YiYuan Road,Bao"an ,ShenZhen,China
Tel: 86(0)755 22208877 Fax:86(0)755 22141877 Website:www.gk-ing.com
If you don't want to receive these Emails, please click unsubscribe.
The first is the 4GB SSD and the second is the 8GB SSD inside my EEE 901
netbook. These old SSDs seem to be from the dumper side of SSD market
and behave more like dump flash with little controller interference.
My guess for the 4GB SSD: erase size 1 Megabyte, page size 2048 Byte
My guess for the 8GB SSD: erase size 2 Megabyte, page size 2048 Byte
Both perform well with up to 9 au, though 8 give a little more speed.
Now I would only need to know how to translate this into fitting
stride/stripe values...
root@Microknoppix:/tmp/flashbench-HEAD-2e30b19# ./flashbench -a /dev/sda
--blocksize=1024
align 1073741824 pre 641µs on 792µs post 567µs
diff 187µs
align 536870912 pre 683µs on 851µs post 577µs diff 221µs
align 268435456 pre 657µs on 847µs post 564µs diff 236µs
align 134217728 pre 626µs on 794µs post 525µs diff 218µs
align 67108864 pre 666µs on 836µs post 582µs diff 212µs
align 33554432 pre 573µs on 732µs post 571µs diff 160µs
align 16777216 pre 577µs on 738µs post 572µs diff 163µs
align 8388608 pre 565µs on 740µs post 563µs diff 176µs
align 4194304 pre 580µs on 735µs post 562µs diff 164µs
align 2097152 pre 552µs on 706µs post 522µs diff 169µs
align 1048576 pre 565µs on 734µs post 547µs diff 178µs
align 524288 pre 548µs on 640µs post 542µs diff 94.7µs
align 262144 pre 546µs on 639µs post 540µs diff 96.1µs
align 131072 pre 547µs on 640µs post 541µs diff 96.1µs
align 65536 pre 536µs on 629µs post 528µs diff 96.7µs
align 32768 pre 535µs on 626µs post 526µs diff 95.6µs
align 16384 pre 534µs on 627µs post 527µs diff 97.2µs
align 8192 pre 558µs on 654µs post 554µs diff 98µs
align 4096 pre 536µs on 633µs post 528µs diff 101µs
align 2048 pre 549µs on 546µs post 550µs diff -3781ns
root@Microknoppix:/tmp/flashbench-HEAD-2e30b19# ./flashbench -a /dev/sdb
--blocksize=1024
align 2147483648 pre 740µs on 890µs post 628µs
diff 207µs
align 1073741824 pre 732µs on 898µs post 603µs
diff 231µs
align 536870912 pre 740µs on 913µs post 590µs diff 248µs
align 268435456 pre 716µs on 890µs post 596µs diff 234µs
align 134217728 pre 694µs on 858µs post 586µs diff 218µs
align 67108864 pre 598µs on 771µs post 575µs diff 184µs
align 33554432 pre 619µs on 788µs post 590µs diff 184µs
align 16777216 pre 624µs on 791µs post 591µs diff 184µs
align 8388608 pre 613µs on 776µs post 578µs diff 180µs
align 4194304 pre 619µs on 781µs post 584µs diff 179µs
align 2097152 pre 617µs on 782µs post 574µs diff 187µs
align 1048576 pre 631µs on 756µs post 632µs diff 125µs
align 524288 pre 634µs on 747µs post 634µs diff 113µs
align 262144 pre 619µs on 717µs post 599µs diff 108µs
align 131072 pre 603µs on 722µs post 601µs diff 120µs
align 65536 pre 627µs on 748µs post 629µs diff 120µs
align 32768 pre 619µs on 743µs post 628µs diff 119µs
align 16384 pre 619µs on 736µs post 621µs diff 116µs
align 8192 pre 622µs on 733µs post 617µs diff 114µs
align 4096 pre 598µs on 721µs post 587µs diff 128µs
align 2048 pre 596µs on 596µs post 598µs diff -1092ns
--
Christian Brandt
life is short and in most cases it ends with death
but my tombstone will carry the hiscore
To ensure delivery of these Emails to your inbox, please add sales(a)gk-ing.com to your email address book.
Christmas Great deal
G&K.Ing enterprise Co.,Ltd
Great deal 7inch MID tablet Usd$56.50/pc
7"800*480 Multi-capacitance screen
Allwinner A10 1.2G CPU
512MB ddr3/4GB flash
Mid tablet
G&K-M701
Built-in 3G/Analog TV/GPS/Bluetooth/Dual SIM card/MTK6575 A9, 1GHz/8GB flash
$112.00/pcs
G&K-702
Android 4.0
A13 1.2GB
4GB flash with camera
$47.50/pcs
G&K-901
Android 4.0
A13 1.2GB
8GB flash with camera
$69.00/pcs
High-end car Gps
G&K-522
5"800*480 Bluetooth/FM/AVIN
Car recorder
128MB/128MB
$58.90/pcs
G&K-536
5"800*480 Bluetooth/FM/AVIN
128MB/128MB
High-end standard
$47.50/pcs
G&K-706
7"800*480 Bluetooth/FM/AVIN
128MB/128MB
High-end standard
$53.00/pcs
Wifi USB
16GB-64GB 802.11 b/g/n
R:10-20MB/S W:8-15MB/S USB Port*1
DC port*1
Usb flash drive
Classical USB Flash
Novel usb flash
Food USB Flash
Credit Card USB flash
Leather USB Flash
Crystal USB flash
Cartoon usb flash
Statement
Dear
Thank for your time .With the development of consumer Electronic, a phenomenon that nots allow to ignore, all the businessmen are in struggle price,low price means low materials cost.
We only can promise our product ,We offered High-end device.our screen,battery,
accessories...all produce with our conscience.hope give help for your business.
Best Regards/G&K.Ing
G&K.Ing Enterprise Co.,Ltd(Shenzhen.China)
Tel: 860755-22208877 E-mail: sales(a)gk-ing.com
http://gk-ing.en.alibaba.com/www.gk-ing.com
If you don't want to receive these Emails, please click unsubscribe.
Hi again,
I've tested another SDHC card. But this time it was a class-4 mini-SDHC with 8GB.
The card is a very cheap one from the German drugstore DM. (No, usually I do not buy my electronics in drugstores ;-) - just a backup card.)
Ok, here are the results. I'm not sure, if my interpretation of them is right.
I've read, that the choice of the underlaying filesystem depends on the amount of open erase blocks.
Is there any rule of best practice for choosing the right filesystem for a particular sd card?
Some feedback would be nice!
Bye, Holger
$ fdisk -l /dev/sdc
Disk /dev/sdc: 7948 MB, 7948206080 bytes
255 heads, 63 sectors/track, 966 cylinders, total 15523840 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: 0x00000000
$ ./flashbench -a /dev/sdc --blocksize=1024
align 2147483648 pre 825µs on 1.19ms post 851µs diff 347µs
align 1073741824 pre 841µs on 1.18ms post 830µs diff 341µs
align 536870912 pre 821µs on 1.14ms post 779µs diff 341µs
align 268435456 pre 842µs on 1.18ms post 818µs diff 346µs
align 134217728 pre 832µs on 1.16ms post 799µs diff 346µs
align 67108864 pre 860µs on 1.16ms post 822µs diff 321µs
align 33554432 pre 832µs on 1.15ms post 802µs diff 331µs
align 16777216 pre 783µs on 1.16ms post 824µs diff 359µs
align 8388608 pre 807µs on 1.1ms post 781µs diff 303µs
align 4194304 pre 817µs on 1.14ms post 786µs diff 340µs
align 2097152 pre 847µs on 924µs post 791µs diff 105µs
align 1048576 pre 791µs on 935µs post 807µs diff 136µs
align 524288 pre 826µs on 906µs post 823µs diff 81.9µs
align 262144 pre 810µs on 926µs post 826µs diff 108µs
align 131072 pre 832µs on 913µs post 801µs diff 96.5µs
align 65536 pre 819µs on 922µs post 830µs diff 97.2µs
align 32768 pre 831µs on 941µs post 807µs diff 122µs
align 16384 pre 772µs on 918µs post 820µs diff 122µs
align 8192 pre 798µs on 845µs post 837µs diff 27µs
align 4096 pre 794µs on 823µs post 806µs diff 22.2µs
align 2048 pre 836µs on 850µs post 801µs diff 31.7µs
## Looks like 4MB erase blocksize and 16KB page size??
$ ./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=1
4MiB 5.41M/s
2MiB 8.97M/s
1MiB 5.98M/s
512KiB 17.1M/s
256KiB 10.9M/s
128KiB 4.25M/s
64KiB 2.13M/s
32KiB 1.06M/s
16KiB 545K/s
8KiB 2.07M/s
4KiB 1.76M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=2
4MiB 8.21M/s
2MiB 5.75M/s
1MiB 18.5M/s
512KiB 16.8M/s
256KiB 10.7M/s
128KiB 4.26M/s
64KiB 2.11M/s
32KiB 1.06M/s
16KiB 545K/s
8KiB 2.05M/s
4KiB 1.69M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=3
4MiB 9.18M/s
2MiB 19.1M/s
1MiB 18.7M/s
512KiB 16.5M/s
256KiB 10.8M/s
128KiB 4.23M/s
64KiB 2.11M/s
32KiB 1.06M/s
16KiB 544K/s
8KiB 1.99M/s
4KiB 1.67M/s
$./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=4
4MiB 10.6M/s
2MiB 19.3M/s
1MiB 18.6M/s
512KiB 16.6M/s
256KiB 10.9M/s
128KiB 4.24M/s
64KiB 2.11M/s
32KiB 1.06M/s
16KiB 544K/s
8KiB 1.86M/s
4KiB 1.53M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=5
4MiB 6.1M/s
2MiB 6.68M/s
1MiB 4.39M/s
512KiB 2.96M/s
256KiB 1.95M/s
128KiB 1.02M/s
64KiB 570K/s
32KiB 334K/s
16KiB 167K/s
8KiB 1M/s
4KiB 1.14M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[4*1024*1024] --blocksize=$[4*1024] --random --open-au-nr=6
4MiB 7.5M/s
2MiB 4.69M/s
1MiB 3.38M/s
512KiB 2.02M/s
256KiB 1.22M/s
128KiB 688K/s
64KiB 406K/s
^C
## Looks like 4.
$./flashbench /dev/sdc -f --erasesize=$[4*1024*1024]
4MiB 4.11M/s 17.4M/s 16.9M/s 5.62M/s 5.18M/s 5.2M/s
2MiB 5.02M/s 17.6M/s 17.2M/s 5.32M/s 5.03M/s 5.21M/s
1MiB 5.28M/s 17.2M/s 17.2M/s 5.53M/s 5.21M/s 5M/s
512KiB 5.04M/s 17.4M/s 5.07M/s 5.21M/s 5.27M/s 5.01M/s
256KiB 5.19M/s 17.1M/s 5.02M/s 5.21M/s 5.02M/s 5.21M/s
128KiB 2.35M/s 16.6M/s 4.96M/s 5.22M/s 4.99M/s 5.18M/s
64KiB 4.98M/s 16.6M/s 5.21M/s 4.91M/s 4.97M/s 5.21M/s
32KiB 2.31M/s 14.8M/s 5.11M/s 4.92M/s 5.12M/s 5.2M/s
16KiB 4.81M/s 12.4M/s 5.07M/s 5M/s 5M/s 4.82M/s
## Looks like the second and the third block were faster than the others.
Hi,
I'm new to the topic of flash benchmarking. I came across reading several articles about this topic, like these in the German Linux Magazin, issue 07/12 and Arnd's linked article on lwn.
I'm currently playing around with a Raspberry Pi that needs a SD card to boot from. (first partition FAT32 for the kernel, second something like ext3/ext4 for the rootfs). I would like to
get the 'best' perfomance out of it, so I also had a look at the flashbench tool. I made some tests with my 32GB Transcend SDHC card and found out, that the card has a 8MB erase block size
and 8KB pages and can handle up to 5 open-au's. (results are listed below)
So what next?
The next step for me is to find out, how to align the partitions correctly. I already talked to Andrew (thx! I was wrong with the erase block size.) who send me the following link that points
to a script that creates two partitions and aligns them correctly.
Is there anything else I can do? ...or am I wrong?
Bye, Holger
--
$ fdisk -l /dev/sdc
Disk /dev/sdc: 32.5 GB, 32462864384 bytes
64 Köpfe, 32 Sektoren/Spur, 30959 Zylinder, zusammen 63404032 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c0bcb
$ ./flashbench -a /dev/sdc --blocksize=1024
align 8589934592 pre 1.04ms on 1.59ms post 1.32ms diff 402µs
align 4294967296 pre 1.04ms on 1.67ms post 1.33ms diff 485µs
align 2147483648 pre 1.03ms on 1.64ms post 1.31ms diff 468µs
align 1073741824 pre 1.02ms on 1.48ms post 1.33ms diff 309µs
align 536870912 pre 1.02ms on 1.5ms post 1.35ms diff 320µs
align 268435456 pre 1.02ms on 1.49ms post 1.28ms diff 338µs
align 134217728 pre 1.02ms on 1.49ms post 1.34ms diff 314µs
align 67108864 pre 1.04ms on 1.48ms post 1.27ms diff 332µs
align 33554432 pre 1.01ms on 1.5ms post 1.32ms diff 330µs
align 16777216 pre 1.04ms on 1.5ms post 1.28ms diff 347µs
align 8388608 pre 995µs on 1.51ms post 1.31ms diff 354µs
align 4194304 pre 1.02ms on 1.35ms post 1.3ms diff 189µs
align 2097152 pre 1.05ms on 1.39ms post 1.31ms diff 209µs
align 1048576 pre 1.04ms on 1.37ms post 1.29ms diff 203µs
align 524288 pre 1.02ms on 1.36ms post 1.32ms diff 192µs
align 262144 pre 1.01ms on 1.33ms post 1.31ms diff 176µs
align 131072 pre 1.03ms on 1.35ms post 1.31ms diff 182µs
align 65536 pre 1.01ms on 1.33ms post 1.26ms diff 195µs
align 32768 pre 1.04ms on 1.37ms post 1.29ms diff 203µs
align 16384 pre 1.04ms on 1.36ms post 1.28ms diff 204µs
align 8192 pre 1.02ms on 1.3ms post 1.27ms diff 154µs
align 4096 pre 1.17ms on 1.16ms post 1.11ms diff 22.6µs
align 2048 pre 1.25ms on 1.24ms post 1.2ms diff 20.2µs
## For me it looks like 8MB erase block size and a 8KB page size. With that in mind, I made the following tests:
$ ./flashbench /dev/sdc --open-au --erasesize=$[8*1024*1024] --blocksize=$[8*1024] --open-au-nr=3 --random
8MiB 17M/s
4MiB 17.2M/s
2MiB 16.5M/s
1MiB 15.9M/s
512KiB 15M/s
256KiB 13.1M/s
128KiB 10.7M/s
64KiB 10.9M/s
32KiB 7.84M/s
16KiB 4.87M/s
8KiB 1.79M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[8*1024*1024] --blocksize=$[8*1024] --open-au-nr=4 --random
8MiB 17.4M/s
4MiB 17.1M/s
2MiB 16.8M/s
1MiB 16M/s
512KiB 15M/s
256KiB 13.4M/s
128KiB 10.8M/s
64KiB 10.9M/s
32KiB 7.89M/s
16KiB 4.87M/s
8KiB 1.79M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[8*1024*1024] --blocksize=$[8*1024] --open-au-nr=5 --random
8MiB 10.3M/s
4MiB 17.1M/s
2MiB 16.7M/s
1MiB 16.2M/s
512KiB 15M/s
256KiB 13.3M/s
128KiB 10.9M/s
64KiB 11M/s
32KiB 7.95M/s
16KiB 4.48M/s
8KiB 1.8M/s
$ ./flashbench /dev/sdc --open-au --erasesize=$[8*1024*1024] --blocksize=$[8*1024] --open-au-nr=6 --random
8MiB 13.4M/s
4MiB 4.27M/s
2MiB 2.26M/s
1MiB 1.2M/s
512KiB 621K/s
^C
## And this looks like 5 open-au in random mode.
$ ./flashbench /dev/sdc -f --erasesize=$[8*1024*1024]
8MiB 17.2M/s 17.8M/s 17.1M/s 17.8M/s 17.5M/s 17.5M/s
4MiB 16.9M/s 17.7M/s 17M/s 17.8M/s 17.5M/s 17.5M/s
2MiB 16.8M/s 17.6M/s 17M/s 17.6M/s 17.5M/s 17.4M/s
1MiB 16.7M/s 17.6M/s 17M/s 17.5M/s 17.4M/s 17.5M/s
512KiB 16.6M/s 17.2M/s 17.4M/s 17.1M/s 16.9M/s 16.5M/s
256KiB 16.4M/s 17M/s 17.2M/s 16.9M/s 16.6M/s 16.6M/s
128KiB 16.5M/s 16.2M/s 16.6M/s 16.3M/s 16.1M/s 16.1M/s
64KiB 16.5M/s 17.1M/s 16.4M/s 17.2M/s 17M/s 17M/s
32KiB 15.4M/s 16.3M/s 15.5M/s 16.1M/s 16M/s 16.1M/s
16KiB 13M/s 13.5M/s 13.2M/s 13.5M/s 13.5M/s 13.5M/s
Hello again,
I have another device to test:
# Product info:
http://www.transcend-info.com/Products/CatList.asp?ModNo=274
$ lsusb
Bus 001 Device 006: ID 8564:1000
$ fdisk -l /dev/sdb
Disk /dev/sdb: 32.5 GB, 32451330048 bytes
16 heads, 48 sectors/track, 82528 cylinders, total 63381504 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: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sdb1 * 18160 63381503 31681672 c W95 FAT32 (LBA)
# This is with factory partitioning
$ sudo flashbench -a /dev/sdb --blocksize=1024 --count=100
align 8589934592 pre 528µs on 603µs post 547µs diff
65.8µs
align 4294967296 pre 523µs on 575µs post 522µs diff
52.5µs
align 2147483648 pre 550µs on 635µs post 551µs diff
84.2µs
align 1073741824 pre 573µs on 640µs post 565µs diff
71.2µs
align 536870912 pre 543µs on 608µs post 562µs diff 55.3µs
align 268435456 pre 536µs on 574µs post 530µs diff 40.9µs
align 134217728 pre 558µs on 607µs post 549µs diff 53.1µs
align 67108864 pre 532µs on 577µs post 515µs diff 53.6µs
align 33554432 pre 568µs on 629µs post 561µs diff 64.6µs
align 16777216 pre 536µs on 598µs post 533µs diff 63.4µs
align 8388608 pre 556µs on 619µs post 556µs diff 62.7µs
align 4194304 pre 566µs on 620µs post 539µs diff 67.5µs
align 2097152 pre 565µs on 604µs post 567µs diff 38µs
align 1048576 pre 568µs on 606µs post 567µs diff 38.7µs
align 524288 pre 563µs on 602µs post 562µs diff 39.7µs
align 262144 pre 567µs on 596µs post 551µs diff 37.5µs
align 131072 pre 564µs on 594µs post 553µs diff 35.6µs
align 65536 pre 553µs on 594µs post 563µs diff 35.3µs
align 32768 pre 555µs on 596µs post 563µs diff 36.6µs
align 16384 pre 557µs on 595µs post 566µs diff 33.4µs
align 8192 pre 561µs on 572µs post 553µs diff 15.1µs
align 4096 pre 556µs on 566µs post 565µs diff 6.04µs
align 2048 pre 553µs on 565µs post 568µs diff 4.85µs
# Okay, I think this indicates 4MB erase blocks (and 16kB page size), so let's
try it with open AUs
$ sudo flashbench /dev/sdb --open-au --erasesize=$[4*1024*1024] --
blocksize=$[4*1024] --open-au-nr=1 --random
4MiB 17.7M/s
2MiB 17.8M/s
1MiB 17.8M/s
512KiB 2.49M/s
256KiB 17.2M/s
128KiB 16M/s
64KiB 13M/s
32KiB 2.19M/s
16KiB 6.37M/s
8KiB 2.54M/s
4KiB 825K/s
$ sudo flashbench /dev/sdb --open-au --erasesize=$[4*1024*1024] --
blocksize=$[4*1024] --open-au-nr=4 --random
Password:
4MiB 17.5M/s
2MiB 17.3M/s
1MiB 4.29M/s
512KiB 4.31M/s
256KiB 16.5M/s
128KiB 14.4M/s
64KiB 4M/s
32KiB 3.42M/s
16KiB 5.74M/s
8KiB 1.68M/s
4KiB 785K/s
$ sudo flashbench /dev/sdb --open-au --erasesize=$[4*1024*1024] --
blocksize=$[4*1024] --open-au-nr=6 --random
4MiB 17.5M/s
2MiB 17M/s
1MiB 3.47M/s
512KiB 16.5M/s
256KiB 16.4M/s
128KiB 13M/s
64KiB 3.24M/s
32KiB 8.26M/s
16KiB 5.68M/s
8KiB 1.3M/s
4KiB 786K/s
# Seems OK so far, but the speed randomly drops under different sizes between
tests, sometimes it's a bit shaky like this:
$ sudo flashbench /dev/sdb --open-au --erasesize=$[4*1024*1024] --
blocksize=$[4*1024] --open-au-nr=6 --random
4MiB 5.8M/s
2MiB 17.3M/s
1MiB 3.47M/s
512KiB 15.9M/s
256KiB 5.52M/s
128KiB 12.8M/s
64KiB 3.24M/s
32KiB 8.19M/s
16KiB 3.43M/s
8KiB 1.52M/s
4KiB 775K/s
# Does this indicate something or it's just device's feature?
# With more open AUs it's slow, also with bigger erase size
$ sudo flashbench /dev/sdb --open-au --erasesize=$[4*1024*1024] --
blocksize=$[4*1024] --open-au-nr=7 --random
4MiB 2.51M/s
2MiB 1.37M/s
1MiB 711K/s
512KiB 362K/s
^C
# Here it's clear...
$ sudo flashbench /dev/sdb --open-au --erasesize=$[8*1024*1024] --
blocksize=$[4*1024] --open-au-nr=6 --random
8MiB 5.93M/s
4MiB 4.38M/s
2MiB 17.4M/s
1MiB 4.34M/s
512KiB 16M/s
256KiB 4.21M/s
128KiB 13.8M/s
64KiB 3.97M/s
32KiB 8.26M/s
16KiB 2.88M/s
# But here I'm not sure, I think it should me much slower if the erase size is
4MB, becouse it would use two erase blocks. So maybe erase size is bigger than
4MB?
On Monday 03 September 2012, Jaroslav Martínek wrote:
>
> Okay, so I did some further tests:
>
> $ sudo flashbench /dev/sdb --open-au --erasesize=$[16*1024*1024] --
> blocksize=$[16*1024] --open-au-nr=1
> Password:
> 16MiB 5.2M/s
> 8MiB 18M/s
> 4MiB 18M/s
> 2MiB 17.3M/s
> 1MiB 17.4M/s
> 512KiB 16.9M/s
> 256KiB 15.9M/s
> 128KiB 15.1M/s
> 64KiB 13.4M/s
> 32KiB 9.98M/s
> 16KiB 6.46M/s
>
> $ sudo flashbench /dev/sdb --open-au --erasesize=$[16*1024*1024] --
> blocksize=$[16*1024] --open-au-nr=3
> 16MiB 8.13M/s
> 8MiB 17.9M/s
> 4MiB 17.3M/s
> 2MiB 17.5M/s
> 1MiB 17.3M/s
> 512KiB 17M/s
> 256KiB 15.7M/s
> 128KiB 14.7M/s
> 64KiB 13.1M/s
> 32KiB 9.64M/s
> 16KiB 6.13M/s
>
> # So far good...
>
> $ sudo flashbench /dev/sdb --open-au --erasesize=$[16*1024*1024] --
> blocksize=$[16*1024] --open-au-nr=4
> 16MiB 8.16M/s
> 8MiB 3.76M/s
> 4MiB 4.92M/s
> 2MiB 5.25M/s
> 1MiB 4.8M/s
> 512KiB 4.76M/s
> 256KiB 4.67M/s
> 128KiB 4.59M/s
> 64KiB 4.38M/s
> 32KiB 3.9M/s
> 16KiB 3.17M/s
>
> # Here it gets much worse, so I would assume, that thist drive can handle 3
> open AUs if the 16 MB erase size is correct? Also note that on the biggest
> size (16 MB) it's slow, but only for the first run, why's that? If repeated,
> it stays on full speed until I change erase size:
What makes one run slow is the garbage collection that happens because of
the state the drive is already in. Writing in small units can cause this
state.
>
> # Now with 8 MB:
> $ sudo flashbench /dev/sdb --open-au --erasesize=$[8*1024*1024] --
> blocksize=$[8*1024] --open-au-nr=3
> 8MiB 4.64M/s
> 4MiB 18.2M/s
> 2MiB 17.6M/s
> 1MiB 17.7M/s
> 512KiB 16.8M/s
> 256KiB 15.8M/s
> 128KiB 15.2M/s
> 64KiB 13M/s
> 32KiB 9.46M/s
> 16KiB 6.14M/s
> 8KiB 2.51M/s
>
> # Seems to be similar to 16 MB
Well, the question is whether using an 8MB size is also fast with more
than 3 erase blocks. If it can have 6*8MB, that would imply only 3*16MB
in the first run. It may be easier to spot the difference between the
two when you pass '--random', but some drives don't like that at all.
> $ sudo flashbench /dev/sdb --open-au --erasesize=$[12*1024*1024] --
> blocksize=$[6*1024] --open-au-nr=3
> 12MiB 2.88M/s
> 6MiB 3.79M/s
> 3MiB 4.65M/s
> 1.5MiB 6.28M/s
> 768KiB 6.22M/s
> 384KiB 6.16M/s
> 192KiB 6.11M/s
> 96KiB 5.96M/s
> 48KiB 5.32M/s
> 24KiB 3.73M/s
> 12KiB 1.95M/s
> 6KiB 1.05M/s
>
> # 12 MB definetely ruled out
right.
> So, it seems to have 16 MB erase blocks? But then, I'm not able to count any
> reasonable block size from these numbers:
>
> $ sudo fdisk -l /dev/sdb
> Disk /dev/sdb: 31,2 GB, 31 161 974 784 bytes
>
> $ factor 31161974784
> 31161974784: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 19 43 97
>
> $ echo $[31161974784 / 1024 / 97 / 43]
> 7296
>
> # 7,125 MB? Weird number...
>
> $ echo $[31161974784 / 1024 / 97 / 43 / 19]
> 384
>
> $ echo $[31161974784 / 1024 / 97 / 43 / 19 / 3]
> 128
>
> # Finally some "round" number, but too small for a 32 GB drive
>
> So, I thought I could be able to count block size from whole drive size, like
> there has to be some number of blocks with same size, which together gives the
> full disk size. Or am I still missing something?
> I did those tests on another smaller flash drive and the results was pretty
> obvious with regard of what i figured out from this list and readme. But this
> 32 GB drive is still a bit cryptic to me.
Yes, some drives are like this
> By the way, are you interested of the results from the other USB drives and SD
> cards I have around here?
Yes, if you have them, then please send them to the mailing list.
Arnd
Hi,
I'm trying to figure out parameters of my USB drive with Flashbench, but I'm a
bit confused with the results.
# Product info:
http://www.adata-group.com/index.php?action=product_feature&cid=1&piid=115
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 31.2 GB, 31161974784 bytes
255 heads, 63 sectors/track, 3788 cylinders, total 60863232 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: 0x0007e2e8
$ sudo flashbench -a /dev/sdb --blocksize=1024
align 8589934592 pre 655µs on 744µs post 644µs diff
95.1µs
align 4294967296 pre 654µs on 774µs post 657µs diff
118µs
align 2147483648 pre 643µs on 804µs post 633µs diff
166µs
align 1073741824 pre 538µs on 562µs post 528µs diff
28.2µs
align 536870912 pre 582µs on 594µs post 562µs diff 21.7µs
align 268435456 pre 576µs on 619µs post 565µs diff 48.3µs
align 134217728 pre 579µs on 637µs post 561µs diff 66.5µs
align 67108864 pre 563µs on 617µs post 567µs diff 51.8µs
align 33554432 pre 537µs on 578µs post 522µs diff 48.2µs
align 16777216 pre 552µs on 563µs post 512µs diff 30.5µs
align 8388608 pre 647µs on 758µs post 646µs diff 111µs
align 4194304 pre 631µs on 726µs post 616µs diff 102µs
align 2097152 pre 629µs on 744µs post 630µs diff 115µs
align 1048576 pre 633µs on 747µs post 623µs diff 119µs
align 524288 pre 641µs on 751µs post 617µs diff 122µs
align 262144 pre 636µs on 742µs post 623µs diff 112µs
align 131072 pre 618µs on 752µs post 643µs diff 121µs
align 65536 pre 604µs on 759µs post 634µs diff 140µs
align 32768 pre 631µs on 741µs post 616µs diff 117µs
align 16384 pre 644µs on 744µs post 624µs diff 111µs
align 8192 pre 636µs on 679µs post 617µs diff 52µs
align 4096 pre 614µs on 641µs post 628µs diff 20.3µs
align 2048 pre 606µs on 629µs post 629µs diff 11.4µs
# Well, from what I've read so far the page size could be 8kB, but what about
the erase block? This drive seems to behave quite differently than the example
in readme or other cards in this list. Any ideas?
Thanks,
Jaroslav Martinek
Hello,
Hope youre having a great day!
I am looking to connect with you and find out if you have any computer & electronic equipment available for donation or recycling.
We are able to offer complete services for the removal, secure data wiping and destruction, charitable donations and tax receipts.
Our donated item are tested for quality and determined whether to be reused, donated to a local charity or handled for environmentally responsible recycling; We are actively working on setting up donations for dozens of charities and organizations across Canada, and your support will help significantly. We have over 1000 charities that currently need our assistance. The list is on our website under charities.
We collect absolutely everything computer and electronic related, including all networking equipment. We adhere to stringent data protection and privacy standards.
If you are not the correct person for this, kindly provide the name of the person in charge of IT, and I will be happy to send them all the appropriate information.
This initiative is not only helping local charities, but also providing your staff an environmentally friendly & secure way to recycle their electronics, computers, and phones.
To explain the program in more detail, please contact me with any questions.
Sincerely,
The Team @ ERA
Account Manager (Lance)
Communication and Events
Electronic Recycling Association
* lance(a)era.ca
þ www.era.ca
( 1.403.262.4488 x 23 | 1.604.215.4483 x 23 | 1.780.455.2088 x 23
Like us on Facebook! www.facebook.com/ElectronicRecyclingAssociation
To be removed from our list reply back with "Remove" is subject.
