BPI-M3 using SSD on SATA-Port

Tom warum nimmst du nicht das neuste Image?

2.Febrary 2016 BPI-Berryboot (Ubuntu Mate 15.10 w/GPU support) http://www.banana-pi.org/download.html

or just released Ubuntu Mate 15.10 for BPI-M3 GPU PowerVR SGX544MP (2016 March 17) http://forum.banana-pi.org/t/ubuntu-mate-15-10-for-bpi-m3-gpu-powervr-sgx544mp-20160317

I know Dragan, both are shit but at least some fixes are inside compare to the one he took from December '15.

In his situation it’s definitely a feature and not a bug not being able to use the so called ‘SATA port’ on the M3 since he wants to use an expensive/fast SSD and not an old laptop HDD lying around.

Using any external USB enclosure his SSD might run up to twice as fast compared to the slowest ‘SATA port’ in the world :smile:

BTW: By reading the log output it looks like udisksd not already being ready directly after startup so in case the SSD should really run permanently in ultra slow mode connected to the ‘SATA port’ then adding it to fstab should solve the problem.

Thanks for the answers. I’ll try the new image and the idea of “fstab” pursue. The goal is to boot from the faster SATA disk. But here I do not understand the use of bpi-bootsel and also can not find the config-file “uEnv.txt”. But this is certainly a new Topic.

Forget about that, the fastest storage device and the one where you should put the rootfs on is the internal eMMC. Using an USB disk (be it connected to the crappy onboard SATA bridge or any more suitable in an external enclosure) will always slow things down.

Booting from SATA and using an SSD is a great idea if you buy a board that features SATA (like the way more cheaper and in most areas also faster Banana Pi M1) but on boards that use the horrible GL830 bridge it’s the worst idea. The interal eMMC is way faster than any disk and especially any device connected to the ‘SATA port’: http://forum.armbian.com/index.php/topic/474-quick-review-of-banana-pi-m3/

Dragan is 100% right. To proof his comment, go to this page on the bottom - in the block-diagramm you see how the SATA is attached. This is also mentioned in the specification table: SATA (up to 2TB USB-to-SATA; GL830)

Fast = eMMC Slow = “SATA”

@Tido I have install Ubuntu Mate 15.10 for BPI-M3 GPU PowerVR SGX544MP (2016 March 17) and here I can use the “uEnv.txt” to boot from USB-device. But here now is the whole advantage of 8 cores CPU by far too low speed USB unusable. One possibility could still exist in the use of Gigabit Lan. For this would greatly help a guide for the use of a fast SATA disk via LAN. Incidentally, for ensuring a CPU clock of 1.8GHz I have established a heat sink with fan operation. So I come under increased CPU load only up to 56 ° C CPU temperature. In order for the 1.8GHz be maintained at all times.

Hi Thomas

Well, at least you’re now a small step further :smile: I am sorry, I never had a M3 in my hand. TK has received a sample and did some testing.

CPU clock, this should be controlled by the software, similar to your PC. no load = save energy high load = increase frequency - work hard. Don’t get Dragan started on that topic - killing cores instead of throttling and so on…

Boot /keep your operating-system in eMMC (please believe it) Keep your data on the harddisk.

Given this information, what do you want to do with the M3 ?

Ok, I have no intention to change the control of the operating system via the clock frequency and CPU temperature! But with the active cooling, I can keep the clock in the upper range of 1.8 GHz. My idea was to use the BPI-M3 as a workstation. And over the LAN should all relevant data stored centrally on a server. So can be accessed from various stations on it. However, it fails precisely because so far (USB speed) that the workstation is even too slow.

The M3 comes with 2x USB 2.0

To sum it up, USB 2.0 specification incorporates speeds: USB 2.0 Hi-Speed 480Mbits/second USB 2.0 Full-Speed 12Mbits/second

480 / 8 = 60Mb/s theoretically. Did you already make some benchmarks with really fast MemoryStick, SSD or HDD ?

If you are not familiar with Benchmarking: Casual benchmarking: you benchmark A, but actually measure B, and conclude you’ve measured C. Good example regarding bonnie++: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html

If you don’t reach good performance identify the bottleneck.

Txt about benchmarking I copied from TK (the forum guru of benchmarking).

I have made test with bonnie++ Here the result: Writing intelligently…done Rewriting…done Reading a byte at a time…done Reading intelligently…done start 'em…done…done…done…done…done… Create files in sequential order…done. Stat files in sequential order…done. Delete files in sequential order…done. Create files in random order…done. Stat files in random order…done. Delete files in random order…done. Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks– Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP bananapi 4G 52 98 29928 28 15772 15 460 99 34705 13 1379 75 Latency 386ms 309ms 552ms 54388us 161ms 761ms Version 1.97 ------Sequential Create------ --------Random Create-------- bananapi -Create-- --Read— -Delete-- -Create-- --Read— -Delete– files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 8400 75 +++++ +++ 11105 81 9610 82 +++++ +++ 10592 82 Latency 1886us 1940us 3003us 1802us 89us 1339us 1.97,1.97,bananapi,1,1459004683,4G,52,98,29928,28,15772,15,460,99,34705,13,1379,75,16,8400,75,+++++,+++,11105,81,9610,82,+++++,+++,10592,82,386ms,309ms,552ms,54388us,161ms,761ms,1886us,1940us,3003us,1802us,89us,1339us

Test on 2016/03/26 bananapi m3 Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf /dev/root 114G 42G 67G 39% / devtmpfs 750M 0 750M 0% /dev tmpfs 1006M 944K 1006M 1% /dev/shm tmpfs 1006M 12M 995M 2% /run tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 1006M 0 1006M 0% /sys/fs/cgroup /dev/mmcblk0p1 256M 61M 196M 24% /boot tmpfs 202M 36K 202M 1% /run/user/1000 tmpfs 202M 28K 202M 1% /run/user/1002

The /dev/root/ is a SSD 128GByte on USB2.0 port

Hi Tom,

Uhh, hard to read… Shitty adjusted forum-software - you couldn’t paste code as code.

Do you still have the file ‘formated’ ? If so can you use this service here http://pastebin.com/ and send us the link? (no sign up needed :slight_smile: )

Here it is.

Someone sent you a link that outlines why to avoid bonnie++ and you use bonnie++?

Banana Pi M3 customers are really somewhat special. Why did you measure? Do you think your M3 does not use the most crappy USB-to-SATA bridge in the world?

Well, this was what you wrote - boonie++ 1.03e suxxs, but Tom tested with v1.97

Take 7 The version of bonnie++ used here was 1.03e, which is currently at the top of the bonnie++ homepage. By going to the experimental releases and running 1.96, I found that the first test has changed. …

Bonnie and bonnie++ are not unusually bad – there are many aspects I like about them, and they have served people well in many cases. The take-away here is to analyze whatever you do use.

About the USB-SATA :

/dev/mmcblk0p1  256M    61M    196M   24% /boot
/dev/root       114G    42G     67G   39% /

The /dev/root/ is a SSD 128GByte on USB 2.0 port

@tomde, can you explain the test scenario : From which storage did you boot the M3? Could you tell bonnie++ to benchmark the SSD on the USB 2.0 port?

By default start bpi m3 from the SD card (/dev/mmcblk0p1) the kernel routine. The file uEnv.txt I modified so that then the boot-file sytem is used by the SSD disk. (… root = / dev / mmcblk0p2 changed to root = / dev / sdb1). The bonnie ++ - test is performed so that the data files are created in the user’s home directory. In my case on the SSD drive.

Nope, by default the M3 tries to start from the only reasonable media you still ignore: the fast internal eMMC. To get an idea how wrong it is to use the ultra slow GL830 USB-to-SATA bridge, install iozone (apt-get install iozone3) and compare using

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

(tests with a few different record sizes). The eMMC is several times faster than anything connected to the crappy GL830:

                                                          random    random
          kB  reclen    write  rewrite    read    reread    read     write
      102400       4     4378     2626     5659     7929     8329     5106
      102400      16    13302    13674    27495    27399    26636    13430
      102400     512    22770    23383    54337    54592    52669    23046
      102400    1024    23582    23381    60522    61165    61159    23364
      102400   16384    24577    25005    72832    72809    72435    25216

Hi Tom,

Take the latest Ubuntu Mate for the M3, then try to follow this information to get the Mate on the onboard eMMC storage.

Please report back if you can now boot without SDcard into Ubuntu Mate 15.10 for BPI-M3 GPU PowerVR SGX544MP (20160317)

Steps seem to be weird, just read carefully: Step 0: copy the Ubuntu Mate 15.10 BPI-M3 image on an USB-MemoryStick. Step 1: Start up the M3 (SBC) with the SD card, on which you have flashed the Ubuntu Mate for BPI-M3 image too. Step 2: Put the USB-MemoryStick which contains the image you’d like to burn to the eMMC Storage to the USB port of the M3. Step 3: Run “fdisk -l” command line on your BPI-M3 and you can see the eMMC path as “/dev/mmcblk1”

sudo fdisk -l

Step 4: Switch to the path of image, and run the command.

cd /dev/sdx
sudo dd if=xxxubuntu-mate-m3-sd-emmc-2016xxxx.img of=/dev/mmcblk1 bs=1M && sync

Step 5: After entering your password, you will not see changes to the terminal until it is finished - wait. Step 6: shutdown -h now Step 7: Now you can safely remove the SD card, and restart the BPI-M3. Step 8: Check if the M3 starts normally from the eMMC storage. Look at the filesystem with:

df -h

(Please re-run the test with bonnie++)

@noralee @sinovoip Will you please update your gitbook with the more precise guide above ? Thank you


He answered your question with his link before and did already what you suggested (just look into http://pastebin.com/fVKfqFpQ – everything is absolutely obvious). And bonnie++ is still not a tool you should use if you’re interested in detailed disk performance.

Hi Tido, I brought the image to on-board eMMC. Here now all the results with iozone: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

from Dragan:
                                                          random    random
          kB  reclen    write  rewrite    read    reread    read     write
      102400       4     4378     2626     5659     7929     8329     5106
      102400      16    13302    13674    27495    27399    26636    13430
      102400     512    22770    23383    54337    54592    52669    23046
      102400    1024    23582    23381    60522    61165    61159    23364
      102400   16384    24577    25005    72832    72809    72435    25216

from tomde:
    Run began: Wed Mar 30 17:32:47 2016

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.

with bootloader and /root on sd-card (32GByte UHS Class 1)

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4      212      242     6193     6172     5080      245
          102400      16     2873     2865    10752    10753     9382     1233
          102400     512     2991     4028    20222    20226    20127     2482
          102400    1024     3473     3337    20777    20806    20711     2791
          102400   16384     4185     4468    21873    21874    21869     4464


with bootloader on /dev/mmcbk0p1 and SSD 128GByte on USB2.0 as /dec/sdb1

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6355     6360     8101     8078     7080     6364
          102400      16    18007    17997    18276    18284    17521    18099
          102400     512    30451    30857    32949    33121    29571    30763
          102400    1024    31181    31144    33396    33451    33076    31401
          102400   16384    34168    34442    34968    34976    34751    34326


with bootloader and /root on onboard emmc

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     4437     6173    15256    15228    13091     4424
          102400      16     7949     5820    34066    34029    30940     3998
          102400     512     5583     4579    56389    56353    56251     3157
          102400    1024    28136    34164    62479    62583    62468    23143
          102400   16384    11280    34688    74056    73980    74003    32260

The worst results are obtained with an SD card. The on-board eMMC provides for the read mode about 2 times faster compared to a SSD disk on USB2.0 port. In write mode, they differ slightly. With regard to higher-capacity SSD disk on USB2.0 port is a good alternative. It is apparent from the measurements that the limit values for the USB2.0 port at a flow rate of about 35 MBytes/s.

Thx for the comprehensive answer! :slight_smile:

Regarding SD cards it really depends on the card in question. While they can’t exceed the ‘usual’ ~22 MB/s limitation regarding sequential transfer speeds there are huge differences regarding random I/O performance. Have a look at this thread here to see how even cheap SD cards with good controllers and high capacity are able to perform: http://forum.pine64.org/showthread.php?tid=469&page=2

You should also be aware that most of the times random I/O is more important than sequential transfer speeds (unless you record or stream video and stuff like that) so I would always have a look at these numbers first.

What puzzles me is the difference regarding random write speeds with small record sizes on your eMMC. It seems you have a different eMMC than me. Can you please compare these values with yours:

                 cid: 1501004d384731474303dc0db061506f 
                 csd: d02701320f5903fff6dbffef8e40400d 
                 rev: 6 
                date: 05/1997 
                name: M8G1GC 
                type: MMC 
preferred_erase_size: 524288 
          cache_ctrl: 0 
          cache_size: 65536 
               fwrev: 0x0 
               hwrev: 0x0 
               oemid: 0x0100 
enhanced_area_offset: 18446744073709551594 
              manfid: 0x000015 
              serial: 0xdc0db061 
          erase_size: 524288 
  enhanced_area_size: 4294967274 

sysfs entry, can’t remember the correct one but you find it quickly using

find /sys -name oemid