lanefu

Moderators
  • Content count

    216
  • Joined

  • Last visited


Reputation Activity

  1. lanefu liked a post in a topic by tkaiser in ZFS on Armbian   
    Not just after Oracle killed Solaris few weeks ago the question arose how to continue with ZFS (me being an absolute ZFS fanboi). After reading ZoL (ZFS on Linux) 0.7 release notes it was just a matter of time to give it a try. On an energy efficient x64 board supporting Intel's QuickAssist (QTA) and also on the most appropriate ARM platform we support for these use cases: Clearfog Pro or Helios4 soon. Release notes state to implement a lot of performance improvements (check the performance section above yourself) so let's give it a try:
     
    Since ZoL is said to be compatible with kernel 4.12 max and we switched already to 4.13 with Armada 38x the best idea is to start with current OMV image for Clearfogs since relying on 4.12 kernel. So with a Clearfog it's just grabbing http://kaiser-edv.de/tmp/NumpU8/OMV_3_0_87_Clearfog_Pro_4.12.9.img.xz, letting it boot, wait for the reboot and then access Clearfog through serial console (or access OMV web UI and enable SSH root login -- see release notes). I built most recent 4.12 kernel plus headers available here http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/
     
    Getting ZFS to work is basically the following: After booting the OMV image ('next' images from dl.armbian.com might work too -- not tested) install headers and kernel package from last link above (you'll be then on kernel 4.12.13), then run armbian-config --> Armbian --> 'Hold -- Freeze kernel and board support packages' to prevent up-/downgrading kernel with 'apt upgrade'. And then simply follow https://github.com/zfsonlinux/zfs/wiki/Building-ZFS
     
    With Armbian/OMV it's just
    wget http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/linux-image-next-mvebu_5.32_armhf.deb wget http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/linux-headers-next-mvebu_5.32_armhf.deb dpkg -i linux-image-next-mvebu_5.32_armhf.deb linux-headers-next-mvebu_5.32_armhf.deb apt install build-essential autoconf libtool gawk alien fakeroot zlib1g-dev uuid-dev \ libattr1-dev libblkid-dev libselinux-dev libudev-dev libdevmapper-dev lsscsi ksh Then follow the instructions above. I did in both directories also a 'make install' and finally executed 'ldconfig' to get the libraries that are installed below /usr/local/lib/ working (see here for details). A final 'echo zfs >> /etc/modules' followed by a reboot and ZFS is ready:
    root@clearfogpro:~# zpool create -f test raidz sda sdb sdc root@clearfogpro:~# zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT test 334G 1.55M 334G - 0% 0% 1.00x ONLINE - root@clearfogpro:~# zpool status pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sda ONLINE 0 0 0 sdb ONLINE 0 0 0 sdc ONLINE 0 0 0 errors: No known data errors root@clearfogpro:~# zfs create -o mountpoint=/var/volumes/raidz -o compression=on test/raidz These are 3 different 120 GB SSDs (SMART output for all of them) as RAIDZ behind 3 different SATA controllers (Transcend in M.2 slot served by Armada 38x directly, Samsung EVO840 attached to an ASM1062 and the Intel 540 behind a Marvell 88SE9215). Armbianmonitor -u: http://sprunge.us/CUHS
     
    Focus of the following tests/research is performance and reliability since it's just a shame that in 2017 users still want to use mdraid/RAID5. A first quick test with 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' failed, without the '-I' iozone is running but results are discouraging (as expected):
    random random kB reclen write rewrite read reread read write 102400 4 5033 4856 242613 243166 18853 168 102400 16 4981 5104 219828 354587 79886 664 102400 512 5006 5069 363717 366405 416668 5330 102400 1024 5029 5068 337919 326607 370943 5335 102400 16384 4856 4878 356314 357925 357245 5087 I better stop with Armbian/Clearfog now and try this on x64 first
  2. lanefu liked a post in a topic by Igor in Mali support announced for mainline (Allwinner SOC's)   

    We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
    https://www.armbian.com/search_gcse/
     

    To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

    Donations are like love. Unconditional.
  3. lanefu liked a post in a topic by guidol in Why are you using Armbian?   
    I like armbian also because it feels (and is while using debian stretch) like debian or any other real linux.
    I dont like these "small" systems whcih only support OpenWRT because it seems either that I cant handle OpenWRT or OpenWRT is very instable.
    armbian/debian is for server type systems and mostly doesnt need the multimedia (video) of a raspberry pi.
     
    When I was young I dreamed about a computer with multiple systems (like in the AMIGA for every work another chip) and now you can make this true with a $10 board and armbian  and without many  fans in the system and no high power level = no noise
  4. pfeerick liked a post in a topic by lanefu in For helping people on other forums -- Orange PI FAQ   
    Save your words.  Just give them this link
     
    Orange PI FAQ
  5. DEHN.IO liked a post in a topic by lanefu in For helping people on other forums -- Orange PI FAQ   
    All really great points, Zador.    Honestly it was meant to be a bit tongue-in-cheek, but I tend view all the non-raspberry development boards as something for more advanced users.   
     
    The Raspberry eco-system is just hard to beat for newer users.   I recognize the price is a important consideration for new people as well, which is probably how many start off with allwinner-based stuff
  6. manuti liked a post in a topic by lanefu in No More Orange Pi plus 2E ?   
    Don't lose hope.. I asked Steven Zhao on Ali in late sept.   His response:
     
    steven zhao 17/09/24 20:19   Yes, we are purchasing the materials for Plus2E now, it will be on stock next month  
     
  7. lanefu liked a post in a topic by pacav69 in AML-S905X-CC. (Le Potato) Documentation   
    I've created a wiki for the libre computer which has instructions for getting started, location of downloads and pinout diagrams.
    more information here
    http://wiki.loverpi.com/sbc-brand:libre-computer
  8. lanefu liked a post in a topic by guidol in Armbian on Sunvell R69 (Allwinner H2+)   
    PS: be aware of the non-Sunvell R69 - which uses the same case, but a Rockchip-CPU and not a Allwinner H2 
    https://www.alibaba.com/product-detail/New-Arrival-Cheapest-4K-Android-TV_60687195434.html
  9. lanefu liked a post in a topic by tkaiser in Improving small H2+/H3 board performance with mainline kernel   
    TL;DR: The small H2+/H3 boards unlike their bigger siblings are all prone to overheating due to smaller PCB size (on the larger boards the PCB's groundplane acts somewhat as a large heatsink dissipating heat away from the SoC). Due to mainline kernel settings not being optimized currently all these boards are slower under constant load compared to legacy kernel. This should change but won't unless someone is looking into it and spends some time on this.
     
    Two areas that deal with this overheating tendency or are somewhat related are
     
    thermal protection / throttling: use the thermal sensor(s) inside the SoC to downclock various engines if specific tresholds are exceeded DVFS (dynamic voltage frequency scaling). All the small boards have either no voltage regulation (NanoPi NEO2) or a primitive one only switching between 1.1V and 1.3V  
    With sun8i legacy kernel Armbian and linux-sunxi community members spent a lot of time and efforts on improving thermal/throttling performance. Read through the following as a reference please: https://github.com/armbian/build/issues/298
     
    The result of our optimizations was a lot of better performance compared to Allwinner's defaults (that targeted only Android and preferred higher single thread performance over overall better performance, with Allwinner settings on an overheating system you could end up with just one or two active CPU cores pretty easily). Now with mainline kernel situation for the larger H3 boards is ok-ish (those boards have an I2C adjustable voltage regulator, voltage switching works fine grained, overheating isn't much of an issue anyway and performance is almost as good as with legacy kernel). But situation with the smaller boards needs some attention.
     
    If we run the cheapest boards currently with mainline kernel then we're talking about these settings:
     
    max cpufreq 1008 MHz (at 1.3V), next lower cpufreq 816 MHz at 1.1V, then 624/480/312/240/120 MHz defined 4 thermal trip points defined starting at 65"C with throttling, then using 75° and 90°C and shutting board down when 105°C are reached.  
    With Armbian and using legacy kernel it's the following instead:
     
    max cpufreq is 1200 MHz, then 1008 MHz still at 1.3V, at 912 MHz we switch to 1.1V and below are a few other cpufreqs available between 816 MHz and 1344 MHz Armbian's legacy kernel provides cpufreq steps every 48 MHz (allowing for fine grained throttling) On the small boards we use twice as much thermal trip points as mainline settings and our strategy is to switch to 912MHz@1.1V pretty early once throttling occurs  
    These differences result in both lower 'normal' performance (since mainline kernel limits also single threaded tasks to 1GHz instead of 1.2GHz) and also 'full load' performance since DVFS/THS/throttling settings are not optimal and once the board reaches the first thermal trip point throttling is not that efficient compared to legacy.
     
    It's easy to test: grab an OPi Zero, NanoPi Duo or any of the other H2+/H3 boards with primitive voltage regulation, then grab an Armbian OS image with legacy kernel (3.4.113 using fex settings) and one with mainline kernel. Execute on both
     
    sudo rpimonitor -r (installs RPi-Monitor so you can enjoy nice graphs when connecting with a web browser to port 8888 of your machine) sudo rpimonitor -p (installs cpuminer which is a great tool to heatup your board and also to measure 'thermal performance' since spitting out khash/s values in benchmark mode minerd --benchmark (this is the actual benchmark running)  
    With mainline kernel performance is lower. Expected result: same performance. What to do? Improve mainline settings.
     
    BTW: Mainline settings currently are as they are since these were the values megi started with last year. Once numbers exist they're only dealt with copy&paste any more.
  10. lanefu liked a post in a topic by TarableCode in NanoPi Duo (plus Mini Shield)   
    You can actually squeeze a NanoPi Duo, RJ45 MagJack (LED,GND pins off), a USB port, and tiny buck converter on a half-size breadboard.


     
    Seems to be working fine with a user built stretch image for the Orange Pi Zero target, at least initially.
    Max current @12vDC I saw was under 400mA with sysbench and WiFi running but more tests are needed.
  11. lanefu liked a post in a topic by tkaiser in H6 boards: Orange Pi 3 Plus and PineH64   
    What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
     
    We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
     
    So all we know is really just:
    H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)
  12. lanefu liked a post in a topic by Igor in Armbian build farm   

    I found out that I can upgrade to 300/50 for no extra money or hardware upgrade and I did it a week ago. Upload is now 5x faster and can be further upgraded but I think there is no need. Daily kernel recompilation is present on the download/repository server until morning - recompilation starts at 00.01. Hopefully, there should be less different kernels to build, so this setup should last. Only server memory is getting low at the moment since we get new sources - I tend to cache them to gain some speed and save SSD. Building utilisation is low at .deb packing and EXTRA packages building as Zador already explained ...
  13. lanefu liked a post in a topic by ebin-dev in Espressobin support development efforts   
     
    Network Manager does have its weaknesses and behaves sometimes erratic.  SBCs with more than one network interface such as the ClearFog Pro, ClearFog Base and  EspressoBin may require more complex configurations (i.e. firewalled router) - to realise that in a reliable way using Network Manager is a nightmare. Even bridged interfaces lead to erratic interruptions during boot.
     
    One could switch to systemd-networkd - it is already installed and just needs to be configured. No more hassles with jobs for raising network interfaces  .
     
    Interfaces wan, lan0 and lan1 are hot-pluggable and work with full speed (iperf3 results are as expected: 112MByte/s and 103MBytes/s in reverse direction). A working example configuration for bridged network interfaces is here:
    #purge network manager: apt-get --purge autoremove network-manager #copy three lines to the interfaces file: cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback #start services and create a symbolic link to resolv.conf: sudo rm /etc/resolv.conf systemctl start systemd-networkd.service systemctl start systemd-resolved.service systemctl enable systemd-networkd.service systemctl enable systemd-resolved.service ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf #create the 5 network configuration files in /etc/systemd/network/ #(do not delete empty lines): cd /etc/systemd/network/ cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge cat 10-dhcp-br0.network [Match] Name=br0 [Network] DHCP=ipv4 cat 10-dhcp-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 cat 10-bridged-lan0.network [Match] Name=lan0 [Network] Bridge=br0 cat 10-bridged-lan1.network [Match] Name=lan1 [Network] Bridge=br0 #and restart systemd-networkd: systemctl restart systemd-networkd  
  14. lanefu liked a post in a topic by Jens Bauer in Armbian build farm   
    This might be close to be off-topic, but I think this is the closest forum for this thread.
     
    Since I read that Igor asked if we know any build-farm services (clouds like Amazon's EC3 or the like), I've been thinking about private build farms.
     
    I imagine that Igor does not have a large build farm (perhaps some boards are contributing with distcc).
    Thomas, what is your setup for building Armbian ? (I imagine that you may have a stronger setup).
    Other developers, please chip in too.
     
    What's been in my mind for a while, is to make a low-cost farm, which would perform well and make things easier and quicker for the Armbian team. There's a lot of maintaining of the source code, so I doubt there's time for expanding compile-clusters.
     
    So my idea is that first of all, I get that ubuntu Xenial running on a 64-bit intel CPU is the minimum requirement for a build-master.
    That is due to some of the tools that Armbian uses. If those tools were able to run on an ARM-based architecture, it would be easier for me to find a good build-master for Armbian (I'm going to use MacchiatoBIN for my own builds).
    The slaves would most likely be MiQi boards as they perform better than even the S912 competitors (but they also use more electricity).
    Finally I plan to use solar power to assist in paying the bill.
     
    When all is set up, I think it would be very useful to add external build slaves as well (such as every developer's build slaves, so that distcc can do the job as quickly as possible. I know that more isn't always better; it depends on the connection speeds and the speeds of the slaves, latencies and a lot of other things.
    -Still the goal is to get an almost 'free' build farm, which is able to build Armbian on its own (so if you're on a non-intel platform (such as PowerPC or ARM), then you will be able to make your own builds anyway by using my build-master.
    On the other hand, if you have a 64-bit intel machine, then it would probably be beneficial to use that as a build-master, because local is usually faster than remote. It can use the compile-cluster for compiling, but the intel-only tools could be run locally.
     
    I might not be able to succeed in all this; it's an expensive project and I have many higher priorities than making a build-farm; but if things go my way, I might be able to move the priorities around (I certainly want to).
    Maybe I'll be able to start out with a few MiQi boards and no build-master and then expand over time.
  15. lanefu liked a post in a topic by ebin-dev in Espressobin support development efforts   
     
    You can compile your own Armbian xenial image with headers (still without asm/*) but with cpufreq support:
    apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build nano ./config/sources/mvebu64.conf #change the last digit in case 'default' to: KERNELBRANCH='branch:linux-4.4.52-armada-17.06' #change to: MAX_SPEED=1000000 ./compile.sh BOARD=espressobin BRANCH=default BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes INSTALL_HEADERS=yes RELEASE=xenial During kernel configuration select: CPU Power Management - CPU Frequency Scaling - Default Governor - ondemand
    and you may disable other governors. Output is Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.87.img with cpufreq ondemand governor enabled..
     
    More information about the Armbian build system can be found here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
     
    EDIT: @lanefu  A commit for changing /config/sources/mvebu64.conf to default KERNELBRANCH linux-4.4.52-armada-17.06 and to MAX_SPEED=1000000 would avoid breaking cpufreq when updating Armbian xenial 4.4.73 images.
  16. reverend_t liked a post in a topic by lanefu in Espressobin support development efforts   
     
    I've been super fascinated with the DSA stuff since my espressobin first exposed me to it's existence.      The thing I don't quite grok with DSA is if I'm trying to do any layer 3 stuff on the switch ports,  such as inter vlan routing is whether or not I'm always limited by the RGMII or whatever link the DSA chip is using to connect to the SoC.    
     
    You have described a pretty ideal board.   A DSA with a cheap 4 core SoC is enough horsepower to brute force doing all sorts of cool network stuff without being so reliant on hardware offloading like on my EdgeRouter Lite.     Now that VyOS has ported their build over to supporting Jessie, I've been hoping to eventually rig up a VyOS installer armbian similar to the OMV userpatches installer.    
  17. lanefu liked a post in a topic by Patrick in Espressobin support development efforts   


    STP is probably https://en.m.wikipedia.org/wiki/Spanning_Tree_Protocol


    Verzonden vanaf mijn iPhone met Tapatalk
  18. lanefu liked a post in a topic by jernej in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    Driver should work (not tested), but DT must be updated.
     
    Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.
  19. lanefu liked a post in a topic by mbee in Orange Pi Zero mainline broken?   
    Hi Igor,
     
    Yes completely understandably.
    I just meant odd in the sense that it's look to be more of a copy paste from opione.
    I will have a look and see if I can get it going and contribute.
     
    regards,
  20. lanefu liked a post in a topic by TarableCode in My weird hipster-y use case   

     
    I'm augmenting my iBook G3 with my pcDuino3 Nano to act as a wireless gateway and host for a development toolchain.
    It's working fine so far and once I'm done it will be completely powered by the FireWire port
     
    The only downsides are that it is a bit big and at idle it's taking ~250mA which I'm going to have to play with at some point and
    see if I can get it down any more.
  21. lanefu liked a post in a topic by mbee in Orange Pi Zero mainline broken?   
    Ahh ok,
     
    Thank you. It seems that the voltage regulator on the zero is supported (its just GPIO) and it has the same regulator as one the orangepi-one. So it should just be a matter of adapting that from the orangepi-one dts and to add DVFS and higher speed to the zero as well.
     
    It's a bit odd that this has not been done but it seems to be implemented on later kernel version.
     
    Thank for your answer!
    regards,
  22. lanefu liked a post in a topic by lupus in Espressobin support development efforts   
    u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750)
     
    With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). 
     
    The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt:
     
    Marvell>> bubt flash-image-XXX_YYY.bin spi usb       
    (XXX: CPU Frequency, YYY: DDR3 Frequency)
     
    'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue)
     
    EDIT:
    With the new firmware I receive I/O errors after some time while accessing the sd card.
    The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them.
    Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.
     
  23. lanefu liked a post in a topic by mantouboji in OPi Zero GPS ntpserver   
    I use the OrangePi Zero.  But it is similar to other model.
     
    It's very simple:
     
    1) use the mainline 4.11.x kernel 
    2) enable the uart1 and pps-gpio in /boot/armbianEnv.txt  like this :
      
    overlays=uart1 pps-gpio param_pps_pin=PA7  
    3) edit /etc/default/gpsd  to use ttyS1 as gps device
    # Devices gpsd should collect to at boot time. # They need to be read/writeable, either by user gpsd or the group dialout. DEVICES="/dev/ttyS1" # Other options you want to pass to gpsd GPSD_OPTIONS="-G -n "  
    4) If you use ntpd,  edit /etc/ntpd.conf like this:
    # GPS Serial data reference server 127.127.28.0 minpoll 4 maxpoll 4 prefer fudge 127.127.28.0 time1 0.135 refid GPS server 127.127.22.0 maxpoll 4 # ATOM(PPS) fudge 127.127.22.0 flag3 1 # enable PPS API  
    5) Or if you prefer crony rather than ntp, install chrony instead of ntp, edit /etc/chrony/chrony.conf , add this to end of it:
    refclock SHM 0 refid GPS precision 1e-1 offset 0.134 delay 0.2 noselect refclock PPS /dev/pps0 lock GPS 6) connect GPS module to UART1 
        GPS      Zero
    ---------------------
       TXD        UART1_RX PIN10
       RXD        UART1_TX  PIN8
      PPS          IO-1  PIN12
     
    7)  use ntpq -p  or chrony sources. to check it.
     

  24. lanefu liked a post in a topic by Igor in Marvell based 4 ports mPCI SATA 3.0   
    Clearfog PRO with Linux 4.12.4-mvebu Samsung 840 PRO utilization:
    iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 62501 101691 98761 94430 34522 93050 102400 16 183325 215091 231439 232948 101667 171875 102400 512 301985 307789 341261 344567 328849 309560 102400 1024 294818 309177 345099 347791 339763 309775 102400 16384 271066 344426 384226 388587 387169 346825 2 x Samsung 840 PRO in RAID0, ext4 utilization:
    random random kB reclen write rewrite read reread read write 102400 4 67614 95508 94561 94984 32561 74157 102400 16 174075 200947 222430 223840 109654 199578 102400 512 307905 294689 317652 308007 307057 268841 102400 1024 307821 317784 327007 330213 322851 317024 102400 16384 286193 383463 394221 398474 397951 374333  
    Logs: http://sprunge.us/CfRS 
    Controller temperature is stable at 64°C, network utilization is also at top speed.  Card was donated via Amazan wish list. Thank you!


     
    Hummingboard 2 with Linux 3.14.79-cubox (mainline not working out of the box)

    Not that impressive as Clearfog,  but works. 
    random random kB reclen write rewrite read reread read write 102400 4 28502 39271 37895 37983 22325 38821 102400 16 68494 80988 69940 70511 53264 80047 102400 512 116594 118132 93789 94280 92828 118884 102400 1024 138185 140277 122610 123717 120853 139393 102400 16384 183976 183169 151745 153813 151890 179652 Logs: http://sprunge.us/OeMY
     
    Espressobin
    2 x Samsung PRO 840, RAID 0, BTRFS
    http://sprunge.us/iBFS
    random random kB reclen write rewrite read reread read write 102400 4 21547 20493 37509 37024 21747 17728 102400 16 61955 56230 93068 93795 64349 45724 102400 512 188611 186828 175688 176961 172098 185109 102400 1024 215817 216559 189477 191846 188481 214727 102400 16384 226764 228502 229162 238883 222826 229894 Intel N4200 / Up2board Square
    1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 65003 76031 93147 92507 32024 73029 102400 16 146880 175968 187734 224409 106025 163916 102400 512 244782 225736 348401 357949 343145 221037 102400 1024 239203 247778 313476 313372 309170 248540 102400 16384 254396 266530 357708 368483 370731 276458 2 x Samsung 840 PRO in RAID 0 random random kB reclen write rewrite read reread read write 102400 4 61680 70018 67650 66635 18221 67984 102400 16 145869 164784 147884 143877 46355 160169 102400 512 230140 219870 213069 199087 213587 210607 102400 1024 273150 271782 257206 279397 275632 271896 102400 16384 314895 311385 365117 376228 375081 317790 Native onboard SATA 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 70611 80842 100647 97276 30072 77666 102400 16 194707 208422 239401 224119 102211 218393 102400 512 346735 410867 401536 425167 396013 412711 102400 1024 374032 366490 378981 394321 382352 368195 102400 16384 441298 430380 475063 486540 482151 414518 Reference: A20's native SATA
     

    This document is work in progress ...
  25. lanefu liked a post in a topic by Igor in Quick Pinebook Preview / Review   
    Update.
     
    Pinebook was my Beachbook for some time. I used it for email, browsing, IRC and terminal. It proved to be sufficient while once it didn't start charging (from 5%) even plugged to charger - unplug / plug back solved that - and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive. My environment did not provide enough motives for exploring the problem deeper