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 
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
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 
)
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 25216Hi 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:
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
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!
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