Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Reputation Activity

  1. Like
    tkaiser got a reaction from rodolfo in Avahi   
    Oh, you wouldn't believe how many network admins hate Bonjour/avahi (and any sorts of auto configuration stuff)
     
    While i agree that having avahi-daemon enabled from the very beginning would be nice it's still a problem adding packets since we also want to stay 'slim' (Ubuntu Xenial for example wants to install the following packages together with avahi-daemon: bind9-host, geoip-database, libavahi-common-data, libavahi-common3, libavahi-core7, libbind9-140, libdaemon0, libdns162, libgeoip1, libisc160, libisccc140, libisccfg140, liblwres141 and libnss-mdns wasting an additional 10MB)
     
    To understand what your request is about... you want to be able to do an
    avahi-browse -rtkp _armbian-ssh._tcp for example to find the board?
     
    I didn't care that much in the past since in the installations where we deploy boards it's both easy to quickly scan the DHCP range (nmap -sV -p 22 192.168.$subnet.1-254) and when it's about one board and a DHCP server implementing dynamic DNS updates then it's also easy to  connect to the Armbian installation since an Orange Pi PC will then be accessible using
    slogin -l root orangepipc (if you look at all the fex files here you get the names of every board we support since we set this name as hostname). Or is your situation different and no DHCP server is available and it's really about Zeroconf networking?
  2. Like
    tkaiser got a reaction from aaiyar in Lamobo R1 - ARMBian 5.0 Jessie Server - Network expert please help   
    Sorry, I won't read lengthy posts that contain already the most problematic part in the title (Lamobo R1). If you want to rely on this crappy piece of hardware and if the R1 should act as a bridge between LAN and WLAN then I would recommend configuring the whole thing just like that. And that means configuring a bridge when the device should be used as bridge!
     
    I don't get it why everyone always wants to deal with TCP/IP packets on layer 3 to solve problems that do not exist when you do it correctly at layer 2 (bridging not routing and not dealing with TCP/IP packets but 802.11 frames instead)
     
    BTW: Unless you do not want to get a bit familiar with networking this won't be solvable. You refer to 'passthrough' which could be either routing (TCP/IP, layer 3) or bridging (layer 2). I would recommend googling for 'debian bridge ebtables' to set up the stuff at layer 2 instead of enabling routing capabilities on the R1 (since then you would have to learn concepts like netmasks and so on)
  3. Like
    tkaiser got a reaction from divode in Quick review of Orange Pi PC   
    Unfortunately even 'branded' PSUs can start to burn so I would both try to reduce the count of PSUs used and always choose their location carefully to avoid flammable stuff around. That's one of the reasons why we choose passive PoE for a bunch of Orange Pi PC: Use one regulated quality 24V PSU and provide power through the 2 unused Ethernet cable pairs to the board where a step-down converter injects 5V through the GPIO pins.
     
    Regarding consumption it depends on the use case as you already said. As can be seen on page 1 of this thread (the review) you can limit maximum consumption to ~500mA pretty easily by using optimised dvfs/cpufreq settings.
     
    In normal useage scenarios it's not that easy to let the board consume more than 1500mA alone (given you use the sane Armbian settings and not the ones found in Orange Pi forums) but USB peripherals add to this when not being behind a powered hub so take this into account since then consumption might exceed 2.5A and you should better use a 3A/4A rated PSU that shows stable voltage.
     
    The most important thing regarding PSU amperage ratings is mostly misunderstood: Voltage drops when consumption increases (see this nice example and especially the footnote regarding Micro USB fortunately avoided with all Orange Pis). Most Orange Pi PC components work still if DC-IN drops to 4.5V but both HDMI and USB peripherals do not tolerate voltage drops below ~4.8V so get a PSU that can handle this.
     
    BTW: The best variant to run in all sorts of annoying troubles is to use both a crappy PSU and a crappy SD card. This will ensure the worst user experience ever
  4. Like
    tkaiser got a reaction from Avinash Ga in High Swap Utilization and CPU Utilization on OrangePi PC   
    Please have a look at https://github.com/igorpecovnik/lib/issues/219  for possible workarounds and solutions. Feedback welcomed.
  5. Like
    tkaiser reacted to Eng-Shien Wu in Orange Pi Plus Images Request   
    Just got my Orange Pi Plus 2 and was under the impression from this thread that I shouldn't expect the internal WiFi to work with Armbian. While building/installing drivers for my 300Mbps WiFi dongle, I was shocked to see WiFi working *without* my dongle plugged in. At first, I thought the drivers activated the internal WiFi (8192eu vs 8192etv), but starting with a fresh image of Armbian (Jessie server), I realized that the internal WiFi worked all along.
     
    This should let you set the SSID and Password
    sudo apt-get install -y network-manager sudo /usr/bin/nmtui-connect It looks like I can push ~40Mbps through the internal WiFi, while my "300Mbps" WiFi dongle manages ~75Mbps. The internal giga ethernet gets ~775Mbps.
  6. Like
    tkaiser got a reaction from wildcat_paris in [RFC] Support Cortex-A53/arm64?   
    Just a small note. To prepare the arm64 switch (GCC 5.2 toolchain strongly recommended) I tried to build OS images using gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf (I simply did an untar below /usr/local and exported PATH=/usr/local/gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf/bin:$PATH prior to calling compile.sh and then tried out the most crappy kernel tree we currently support. Works as expected:
    Linux version 3.4.110-sun8i (tk@opennms) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-1) ) #86 SMP PREEMPT Mon Feb 29 20:23:08 CET 2016  
     
     
    Therefore I would suggest to do the same with all images (kernel debs), put them somewhere on mirror.igorpecovnik.com and ask experienced users to try them out. If this works we could integrate the 5.2 Linaro toolchain in our build system to also prevent strange effects when people try to build from source on systems where exotic cross-compile toolchains are present.
     
    Any thoughts?
  7. Like
    tkaiser reacted to Igor in [Odroid C2] root login problem.   
    Yes, there are some 32bit binaries which needs to be fixed, but nothing is critical. There should be no problem with login except showing an error.
     
    & thanks, I am happy that you give a try. The system will be improved and issues fixed. This was more or less first C2 and first arm64 build.
  8. Like
    tkaiser got a reaction from Avinash Ga in How to check temperature of OrangePi PC   
    If you use the most recent image for H3 boards then the SoC temperature is available as /etc/armbianmonitor/datasources/soctemp otherwise have a look into /sys/class/thermal/thermal_zone1/temp
     
    And you can also do monitoring by starting 'armbianmonitor -m' which shows relevant system parameters including CPU clockspeeds and temperature. Looks then like this: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-194980231
  9. Like
    tkaiser got a reaction from manuti in Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!   
    It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
     
    Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
     

     
    RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
     
    If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
     
    So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
     
    C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
    John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
     
    Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
     
    How does Armbian differ:
    We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
     
    When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
     
    The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
     
    To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
     
    The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
     
    Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
     
    The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
     
    TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)
  10. Like
    tkaiser got a reaction from Avinash Ga in [RFC] Support Cortex-A53/arm64?   
    Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users
     
    BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.
  11. Like
    tkaiser got a reaction from Nick in How can I compile a headless server kernel 4.1+ for the OrangePiOne ?   
    Jef Moine has made a driver (not tested by me, not included into kernel tree and maybe that will never happen with this driver): http://moinejf.free.fr/opi2/
  12. Like
    tkaiser got a reaction from technik007_cz in backup & restore   
    Cloning is not backup. Never.
     
    To create a clone from time to time that can be transferred to a new SD card on a Linux PC two steps are necessary: After connecting the card, you simply transfer the 1st MB to a file by doing:
    dd if=/dev/$card of=u-boot_spl_partition-table.img bs=1M count=1 You use the whole device here and not a partition since you want u-boot+spl. Then you mount the first partition to eg. /mnt/armbian/ and then create one huge compressed tar archive excluding uneeded stuff relying on this list (paths need to be relative therefore remove the leading slashes):
    cd /mnt/armbian/ && tar -czf clone.tar.xz --options=compression-level=9 --exclude-from=$exclude-list * Your PC is fast and SD cards are slow so this is the best variant to create an archive with minimal size in minimal time. If you want to use this stuff with a new SD card later simply write u-boot_spl_partition-table.img with dd to the new card, use parted or gparted to adjust/fix the partition table, mount the first partition and then do a
    cd /mnt/armbian/ && tar -xf clone.tar.xz But this is not backup but just a clone. Backups need versions to be able to recover from accidents. In case a x86 Linux box is involved a more reasonable approach would be to use a btrfs FS with maximum ZLIB compression on the PC and then either create snapshots on the SBC (when used with mainline kernel and using btrfs for the rootfs -- Armbian is capable to benefit from btrfs thanks to Zador!) and send them using btrfs send/receive or in case you have to use ext4 on the SBC use rsync to send the changes to the PC (and use btrfs snapshots there or rsync with hardlinks to store multiple copies of data without wasting space).
     
    For desaster recovery you still only need the 1MB file u-boot_spl_partition-table.img created sometimes before (or use the appropriate u-boot package from apt.armbian.com) and can then transfer the contents of your backup storage to a new SD card.
     
    In case you have a bunch of SBCs that need to be backed up then better use deduplication instead of compression on the Linux PC (also a btrfs feature worth a look)
  13. Like
    tkaiser got a reaction from rodolfo in backup & restore   
    This is still not backup since backup needs versioning (to protect from accidentally damaging/deleting files). And 100% identical clones can be created way more efficient.
     
    One approach is to use rsync combined with hardlinks (web search for "rsync hardlinks backup" or something like that) and anyone using mainline kernel should have a look into btrfs snapshots and 'btrfs send/receive'.
  14. Like
    tkaiser reacted to Nix in opi pc - usb disconnects?!   
    Next time it occurs, I will do more testing and provide more feedback. Stay tuned
  15. Like
    tkaiser got a reaction from RagnerBG in Kodi/XBMC on Armbian with HW Accleration possible?   
    By applying them?
     
    https://github.com/rellla/lib/tree/ump
     
    It seems everything needed are these two patches, then you can build kernel packages and simply try it out. Please report back and have also a look at http://linux-sunxi.org/User:Rellla/Armbian
     
    EDIT: Kernel package with patches and appropriate CMA settings: kernel-cma_ump-sun7i_5.06_armhf.tgz Please test and report back.
  16. Like
    tkaiser got a reaction from Nick in Help booting Orange Pi PC   
    So you tried out nearly everything but Armbian and are asking now in an Armbian forum what to do next? Really?
     
    One of the many differences between Armbian and everything you already tried out is that our OS images use sane/safe DRAM and sane/safe CPU clockspeeds. In case you bought a lemon board that might make the difference.
  17. Like
    tkaiser reacted to Igor in Armbian for Odroid C1 and C2   
    We got first version  ... boots, runs, but I could not set different resolution, so some further hacking is needed.
     
    http://www.armbian.com/odroid-c2/
  18. Like
    tkaiser reacted to Igor in Armbian for Odroid C1 and C2   
    Kernel boots:
    uname -a Linux odroid64 3.14.29-odroidc2 #4 SMP PREEMPT Thu Mar 24 09:10:24 CET 2016 aarch64 aarch64 aarch64 GNU/Linux
  19. Like
    tkaiser got a reaction from Jens Bauer in Best budget device as torrent box?   
    BTW: I chose the Orange Pi Plus as an example for a reason. Since this is a device where everyone will get the idea that it's necessary to test stuff individually.
     
    When you connect a SATA disk to the Orange Pi Plus which seems the most reasonable choice you probably won't see any performance improvement compared to CubieTruck now. If you use the very same SATA disk, put it in an external enclosure and connect it through USB then performance will improve. Why? Is SATA and USB different on the Orange Pi Plus? No, it's just the H3 SoC features no SATA and the SATA port on the OPi+ has been implemented using the slowest USB-to-SATA bridge in the world (GL830) which isn't able to exceed 15 MB/s write speeds and will be outperformed by any external USB disk not relying on GL830.
     
    So refusing to 'benchmark correctly' will just lead to another frustrating situation and a device you might throw into the bin. Measuring all the stuff individually you're able to identify the real bottlenecks and improve the situation.
     
     
    In case you asked me: Sure, you can always loose data as long as you're not doing backups
     
    Really, running any sort of real benchmark might put significantly more load on a device which might lead to stability problems caused by an insufficient PSU for example. The 'armbianmonitor -c' check was designed to verify the speed/reliability of SD cards and thumb drives (and no, the tests do not destroy anything, just try to fill the storage in question with test patterns that are verified later) but being used with a disk and insufficient power supply they might lead to data/filesystem corruption.
     
    But that's what benchmarks are for (when used in an active approach), identifying bottlenecks be it performance or reliability relevant. In case anyone's interested: We used the linpack high performance benchmark to identify reliability issues caused by undervoltage settings with Pine64 in the past: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-196399188
  20. Like
    tkaiser got a reaction from Nick in Pi Clusters   
    Regarding stuff on a NAS: If it's a bit more intelligent NAS (I hope you use FreeNAS or something and not proprietary bullsh*t? ) then switching to SAN mode might speed up things like an Armbian build a lot.
     
    NAS = SMB/NFS for example
    SAN = iSCSI for example (the build host just uses the remote share/LUN as a block device with a local filesystem on top which makes a difference regarding use of FS caches/buffers that can speed up a few operations 100 times or even more)
     
    Switching from NAS to SAN not only increases random I/O (or let's better say frequent write/read operations on a large bunch of small files) a lot but also helps if the network connection is the bottleneck by using transparent filesystem compression. If you put an uncompressed desktop Armbian image on a NAS (~2GB) and you've a GbE connection only then sequential read/write transfer speed won't exceed ~100MB/s. If you do the same with an iSCSI LUN and btrfs with compression=zlib on top sequential transfer speeds will be 2.5 - 3 times faster.
     
    And in case both NAS and build host have 2 NICs you might be able to double the speed again by using I/O multipathing (not possible with NAS and link aggregration).
     
    So as usual: 'work smarter not harder' is the most important factor (but using a fast SSD will do even better )
  21. Like
    tkaiser got a reaction from Nick in Pi Clusters   
    Anyway, as long as it supports iSCSI reliably a superiour way to combine a VM (hosted on Windows, Linux or OS X) with iSCSI storage is
    define a local datastore to be used for /boot and / assign the VM as much CPU cores as possible install Ubuntu Xenial there setup iSCSI from within the Ubuntu VM create a btrfs FS on the iSCSI LUN with compression=zlib move the Armbian build environment to this place This might speed things up a lot since in situations where I/O has been the bottleneck before now local filesystem semantics improve random I/O and sequential transfer speeds explode since CPU cores jump in by compressing the data on the fly. Since the different steps in an Armbian build are either CPU or I/O intensive you won't loose performance when CPU cycles are 'wasted' improving sequential transfers between SAN and VM.
  22. Like
    tkaiser got a reaction from Jens Bauer in [RFC] Support Cortex-A53/arm64?   
    Hi,
     
    since a Geekbox (Rockchip RK3368) and two Pine64+ (Allwinner A64) are collecting dust and at least for the latter longsleep already prepared a nice image build process that makes including a 'foreign' rootfs quite easy I thought about supporting arm64 also and not just only armhf.
     
    But I still lack oversights over our own build process or don't know in which direction other devs will move (I saw zador rearranging stuff the last days) so I thought I better ask first instead of hacking around
     
    I thought about adding a global variable defaulting to "armhf" and setting it to "arm64" for the new boards in configuration.sh since we later have to call
    make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- debootstrap --arch=arm64 My goal for now is just being able to spit out an Armbian arm64 rootfs (RELEASE="jessie"/"xenial") I can use with longsleep's image build process to get an idea how far we get with arm64 now (both 3.10.65 and mainline). But I also thought about doing it right from the beginning and stop doing q&d hacks...
     
    Any thoughts?
  23. Like
    tkaiser got a reaction from Jens Bauer in [RFC] Support Cortex-A53/arm64?   
    Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users
     
    BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.
  24. Like
    tkaiser got a reaction from wildcat_paris in [RFC] Support Cortex-A53/arm64?   
    Success!
     
    macbookpro-tk:~ tk$ slogin 192.168.83.88
    tk@192.168.83.88's password: 
     ____  _             __   _  _         
    |  _ \(_)_ __   ___ / /_ | || |    _   
    | |_) | | '_ \ / _ \ '_ \| || |_ _| |_
    |  __/| | | | |  __/ (_) |__   _|_   _|
    |_|   |_|_| |_|\___|\___/   |_|   |_|
                                           
     
    Welcome to ARMBIAN Ubuntu 16.04 3.10.65+ 
     
    System load:   0.08            Up time:       2 min
    IP:            192.168.83.88
    CPU temp:      30°C           
    Usage of /:    16% of 3.5G   
     
    Last login: Mon Feb 29 12:03:04 2016 from 192.168.83.91
     
    tk@pine64plus:~$ uname -a
    Linux pine64plus 3.10.65+ #31 SMP PREEMPT Sun Feb 28 18:55:54 CET 2016 aarch64 aarch64 aarch64 GNU/Linux
    tk@pine64plus:~$
     
    Just kidding, I only used longsleep's Xenial OS image for Pine64 to get a clue what to expect when switching to Xenial (for example packages missing, eg. figlet/toilet) and arm64 in general. I believe it's good to 'just have a look' now before starting to adjust our new templates
     
    BTW: I used 'sysbench' the last 2 years to roughly compare performance of ARMv7 boards. Not possible any longer when running on ARMv8 with software compiled for ARMv8:
     
    tk@pine64plus:~$ sysbench --test=cpu run --num-threads=4
    sysbench 0.4.12:  multi-threaded system evaluation benchmark
     
    Running the test with following options:
    Number of threads: 4
     
    Doing CPU performance benchmark
     
    Threads started!
    Done.
     
    Maximum prime number checked in CPU test: 10000
     
     
    Test execution summary:
        total time:                          3.2562s
        total number of events:              10000
        total time taken by event execution: 12.9950
        per-request statistics:
             min:                                  1.21ms
             avg:                                  1.30ms
             max:                                 13.14ms
             approx.  95 percentile:               1.30ms
     
    Threads fairness:
        events (avg/stddev):           2500.0000/10.70
        execution time (avg/stddev):   3.2487/0.00
     
    (the Raspberry Foundation uses the very same silly benchmark and published today benchmark results for the yet available RPi 3: also ARMv8 based but not that impressive: 49.02 seconds that's just 15 times slower than A64! Maybe they get the idea why it would make sense to make use of Aarch64/ARMv8 architecture and not let code for ARMv6 run on ARMv8 cores in ARMv7 mode )
     
    And running these sorts of benchmarks only for a few seconds like above is pretty useless since thermal throttling should also be considered (this happens when sysbench runs for a few minutes and the A64 wears already a heatsink):
     

     
    (I made an RPi-Monitor template for A64 already available). Even with this light workload already throttling occurs and CPU frequency will be reduced. And then I tried to run ssvb's new Cortex-A53 cpuburn version but the Pine64+ immediately deadlocked. Seems I have to buy the new 2.5A PSU for RPi 3 to compensate the crappy Micro USB DC-IN connector also used on the Pine boards.
  25. Like
    tkaiser got a reaction from Jens Bauer in Quick review of Solidrun's Clearfog   
    The write speed must be limited by the SSD (small capacity --> less parallelism --> slow write speeds). I hope these little beasts arrive soon:
     

    Will then try to do some tests with some SSDs in parallel. BTW: 15 minutes ago a packet from Solid-Run arrived:
     

     
    Wow, up and running within 10 minutes including download of your Armbian image: http://pastebin.com/Y3vJmX3H
     
    Great first experience. Everything already provided to start through (onboard UART-to-USB adapter, PSU adapter, TF card).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines