0
tkaiser

Quick Review of NanoPi K1 Plus

Recommended Posts

nanopik1plus.png

 

Quick look at NanoPi K1 Plus. As usual comprehensive documentation available in FriendlyELEC's wiki.

 

Board is based on Allwinner H5 (able to clock up to almost 1.4GHz thanks to I2C accessible voltage regulator) and is compatible to RPi form factor. It comes with 2 GB dual-channel DRAM, Gigabit Ethernet and RTL8189 based Wi-Fi, exposes the three USB2 host ports as type A receptacles and USB OTG on Micro USB.  The board also uses FriendlyELEC's own eMMC connector. Why they invented an own one can be easily seen on NanoPi NEO4: saves PCB space.

 

Powering is possible through Micro USB (high quality Micro USB cable is provided). Besides that the usual interfaces are available at the usual locations but not everything is supported currently by Armbian (e.g. CSI camera input -- you need to take FriendlyELEC's software offers for this).

 

Currently Armbian settings are a bit limited (max cpufreq 1152 MHz) but in the future we might unlock higher clockspeeds (up to 1368 MHz). Also needing some corrections: the thermal settings since currently the SoC starts to throttle already at 65°C.

 

Since FriendlyELEC sent an 8 GB eMMC module and I had my usual EVO840 lying around I checked storage performance using our usual iozone calls:

8 GB eMMC                                                     random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6830     7119    13905    13917    12040     6914
          102400      16    20064    20519    31848    31884    29348    19759
          102400     512    29217    28815    44536    44529    44325    28363
          102400    1024    29247    29291    44801    44796    44678    29084
          102400   16384    28519    29488    45031    45025    45025    29227

Samsung EVO840 via USB2/UAS                                   random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     8550    10913     8310     8321     8337    10888
          102400      16    21807    24395    21737    21809    21860    25063
          102400     512    37468    37704    40780    41035    40997    37808
          102400    1024    37929    38104    41271    41499    41488    38119
          102400   16384    37099    38329    41796    41946    41958    38313
         1024000   16384    38249    38414    41976    41997

So USB2 storage performance couldn't be better with nice high random IO scores and sequential transfers maxing out at ~40MB/s. But there's some room for improvement wrt eMMC. Just 29/45 MB/s write/read are not that spectacular though random IO numbers are excellent!

 

Network performance: Wireless not worth to test (2.4 GHz with 1T1R antenna setup will max out at 40 Mbps), with Gigabit Ethernet it looks fine (iperf3 test):

RX direction:
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver
TX direction:
[  4]   0.00-10.00  sec  1.02 GBytes   879 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.02 GBytes   878 Mbits/sec                  receiver

 

I added preliminary sbc-bench results here and there is full debug output: http://ix.io/1m3J

Share this post


Link to post
Share on other sites

Thanks for the review!  Extremely helpful to inform wether to buy or not.

 

I never expected to see 40MB/sec file transfers over USB2.  Without reading this review of yours, I would have never even considered this board, thinking "Not even USB3, let alone SATA?  No way.  The disk I/O would suck too badly."

Share this post


Link to post
Share on other sites
1 hour ago, esbeeb said:

I never expected to see 40MB/sec file transfers over USB2

 

If UAS (USB Attached SCSI) is available at least with Allwinner USB that's quite normal. Funnily more beefy platforms perform lower in this area -- see for example RK3399 with same SSD connected to USB2:

EVO840 / USB2 / RK3399                                        random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     5570     7967     8156     7957     8156     7971
          102400      16    19057    19137    21165    21108    20993    19130
          102400     512    32625    32660    32586    32704    32696    32642
          102400    1024    33121    33179    33506    33467    33573    33226
          102400   16384    33925    33953    35436    35500    34695    33923
         1024000   16384    34120    34193    34927    34935

EVO840 / USB2 / Allwinner H5                                  random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     8550    10913     8310     8321     8337    10888
          102400      16    21807    24395    21737    21809    21860    25063
          102400     512    37468    37704    40780    41035    40997    37808
          102400    1024    37929    38104    41271    41499    41488    38119
          102400   16384    37099    38329    41796    41946    41958    38313
         1024000   16384    38249    38414    41976    41997

High sequential transfer speeds are only important for a few use cases (e.g. storing big files on a NAS) but for the majority of both use cases and people random IO performance is more important (and here every USB2 attached SSD outperforms every HDD, even SATA or SAS attached -- simply since spinning rust always sucks in this area and shows horrible low IOPS and high latency at the same time)

Share this post


Link to post
Share on other sites
13 minutes ago, ag123 said:

that heatsink is impressive

 

Nope :(

 

A few issues affect 'thermal performance' of the board:

  • The heatsink is quite small
  • This is a 40nm SoC so much more heat is generated at same clockspeed compared to 28nm SoCs like RK3328 for example. 2GHz are impossible, the best you get is close to 1.4GHz which already drives H5 with a Vcore voltage way beyond sane values (1.4V)
  • Heat transfer between SoC and heatsink is far from ideal. The thermal pads FriendlyELEC ships are as inefficient as all those pads. Replacing this with a copper shim of same height and using a thin film of thermal compound should improve heat dissipation a lot (see my experiments with RockPro64 and NanoPC T4)
  • With current settings throttling thresholds are way too low. We start already at 65°C with throttling. Increasing this to at least 75°C or even 80°C should be part of further Armbian optimizations

IMO @mindee should evaluate somewhat better heat dissipation. Though I don't think replacing the thermal pad with a copper shim is a good general solution and I fear providing a heatsink to directly mount on the SoC with a better profile requires CNC milling and adding thermal compound would increase costs way too much. Not that easy...

Share this post


Link to post
Share on other sites

thanks for the response! prior to meddling with opi vs asus tinkerboard rk3288

i ran into the dilemma that price of 1 asus tinkerboard : 4 or more orange pi one

in the end the economy of orange pi one wins :lol:

but of course rk3288 is much faster than h3

rk3288 boards are more suitable for "desktop" use cases they could literallly replace a desktop and is rather fast,

while i think h2+/h3 more suitable for "iot" use cases many of those boards target the 'tiny' form factor as well but sacrificing ram etc

 

Share this post


Link to post
Share on other sites
On 9/6/2018 at 11:01 AM, tkaiser said:

A few issues affect 'thermal performance' of the board

 

Since I just realized that with this board/heatsink combo FriendlyELEC ships a thermal pad that is 2mm thick I decided to test further.

 

4 different setups were tested with the board in same external condition. Ambient temperature 24°C, board lying flat on a table (except the last test with open enclosure in upright position). I used my sbc-bench tool in 'thermal test mode' with the following command execution:

sbc-bench.sh -T 64 ; sbc-bench.sh -t 45

First test is just to pre-heat the board so that second test always runs with as identical conditions as possible. 'sbc-bench.sh -T 64' ensures that the whole boards has been heated up for more than 10 minutes and the subsequent 'sbc-bench.sh -t 45' will force the tool to wait for the SoC temperature to get as low as 45°C before the real test starts.

 

The measurement is done with cpuminer's benchmark mode. With an unthrottled NanoPi K1 Plus at 1368 MHz the score should be around 3.80 kH/s. Let's see how the different setups perform (please keep in mind that currently we clock only up to 1152 MHz but as can be clearly seen this is already a challenge to keep this clockspeed since throttling always occured). The kH/s value is from the end of the 5 minute benchmark execution (when throttling is expected to be worst):

  1. neither heatsink nor enclosure: 3.06 kH/s (full details)
  2. enclosure with heatsink + thick thermal pad: 3.06 kH/s (full details)
  3. enclosure with heatsink + thinner thermal pad: 3.06 kH/s (full details)
  4. open enclosure standing vertically with heatsink + thinner thermal pad: 3.13 kH/s (full details)

So obviously no difference between 1), 2) and 3)? Nope, let's look at the amount of time spent on each individual clockspeed (forced by cpufreq and thermal frameworks):

                 1)          2)          3)          4)
  1152 MHz:    3.93 sec    9.94 sec   10.98 sec   13.47 sec
  1104 MHz:    4.35 sec   14.85 sec   15.36 sec   28.16 sec
  1056 MHz:   13.57 sec  124.16 sec  119.55 sec  228.23 sec
  1008 MHz:  271.83 sec  151.40 sec  154.46 sec   30.47 sec
   960 MHz:    6.66 sec       0 sec       0 sec       0 sec

So with our setup (starting at 45°C with the test and let throttling already happen at 65°C) we can see clearly that regardless of which variant is chosen throttling almost instantly happens. It's not even 4 seconds without any heatsink and just 14 seconds with heatsink + thin thermal pad in an open enclosure. Please keep in mind that our test tool cpuminer makes heavy use of NEON optimizations and is therefore able to generate more heat than other 'benchmarks' like stress-ng or sysbench are able to produce. In reality heat generated by maximum CPU utilization will be less.

 

Talking about thermal pads: I started with FriendlyELEC's supplied blue thermal pad (2mm thick) just to replace it with the one I got with NanoPC-T4 (1mm thick). The differences between 2) and 3) show that the effects are negligible: the thinner pad's 'performance' is almost the same as the thicker one. In contrast to this opening the enclosure and putting it in an upright position is a lot more efficient since now the additional airflow helps transferring heat away from the heatsink.

 

Possible insights:

  • Tiny enclosures suck. At least the insulating ones made from plastic. Metal enclosure that establish good contact with the SoC and therefore act as heatsink themselves are something entirely different
  • The thickness of thermal pads between heatsink and SoC at least in this test doesn't matter that much (or at all). Needs further investigation
  • Replacing the thermal pad (horribly low thermal conductivity) with something better like a copper shim plus thermal compound really improves situation (see few posts below)
  • Thermal readouts are somewhat off. See first line reported with last test: 'WARNING: sysfs thermal readout is ominously low: 17°C.' -- the room temperature is 24°C so 17°C reported are clearly wrong. Maybe it's just a matter of calibration -- no idea, haven't looked into thermal issues on Allwinner since ages.
  • Test execution wrong due to lazyness. I used two boards, the left one for 1), the right one for 2) - 4). If thermal readouts are expected to be wrong and we don't know why all tests have to happen on the same board. But honestly: to get an idea whether 'no heatsink at all' performs poorly this is IMO sufficient

Below both boards and in the foreground thermal pad from my RockPro64 (replaced by copper shim in the meantime) and the original 2mm thermal pad from K1 Plus:

 

NanoPi_K1_Plus_and_Thermal_Pads.jpg

 

Share this post


Link to post
Share on other sites
5 hours ago, tkaiser said:

With current settings throttling thresholds are way too low. We start already at 65°C with throttling. Increasing this to at least 75°C or even 80°C should be part of further Armbian optimizations

 

thermal-zones {
        cpu_thermal: cpu_thermal {
            polling-delay-passive = <330>;
            polling-delay = <1000>;
            thermal-sensors = <&ths 0>;

            trips {
                cpu_hot_trip: cpu-warm {
                    temperature = <75000>;
                    hysteresis = <2000>;
                    type = "passive";
                };
                cpu_very_hot_trip: cpu-very-hot {
                    temperature = <100000>;
                    hysteresis = <2000>;
                    type = "critical";
                };
            };

            cooling-maps {
                cpu-warm-limit {
                    trip = <&cpu_hot_trip>;
                    cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
                };
            };
        };


    };

Share this post


Link to post
Share on other sites
2 hours ago, @lex said:

cpu_hot_trip: cpu-warm

...

cpu_very_hot_trip: cpu-very-hot

 

Hmm... I went this route adjusting the fine-grained ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch. It's just increasing first thermal trip points by 10°C but leaving upper limits as they are. Results with K1 Plus (in enclosure with thin thermal pad) in 3.11 kH/s at the end of the 5 minute cpuminer run compared to 3.06 kH/s before (full results for old settings vs. new settings)

 

Time spent on cpufreq OPP:

                before      after
  1152 MHz:   10.98 sec   76.09 sec
  1104 MHz:   15.36 sec   36.09 sec
  1056 MHz:  119.55 sec  165.10 sec
  1008 MHz:  154.46 sec   23.04 sec
   960 MHz:       0 sec       0 sec

So yes, there's an improvement but another problem is that our DVFS settings for H5 are super conservative (VDD_CPUX pretty high everywhere) while FriendlyELEC chose way lower settings. This will always result in K1 Plus running Armbian (or any other distro using 'plain' mainline) being slower with heavy loads compared to FriendlyELEC OS images.

 

And I don't see anyone caring about stuff like this. Early 2016 @zador.blood.stained and me invested a lot of time and efforts in developing sane and performant thermal/DVFS settings for Allwinner A64 and H3 (legacy kernel). No idea whether anyone will do the same for H5 or any other SoC running with mainline today...

Share this post


Link to post
Share on other sites
On 9/6/2018 at 4:00 PM, tkaiser said:

 

If UAS (USB Attached SCSI) is available at least with Allwinner USB that's quite normal. Funnily more beefy platforms perform lower in this area -- see for example RK3399 with same SSD connected to USB2:


EVO840 / USB2 / RK3399                                        random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     5570     7967     8156     7957     8156     7971
          102400      16    19057    19137    21165    21108    20993    19130
          102400     512    32625    32660    32586    32704    32696    32642
          102400    1024    33121    33179    33506    33467    33573    33226
          102400   16384    33925    33953    35436    35500    34695    33923
         1024000   16384    34120    34193    34927    34935

EVO840 / USB2 / Allwinner H5                                  random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     8550    10913     8310     8321     8337    10888
          102400      16    21807    24395    21737    21809    21860    25063
          102400     512    37468    37704    40780    41035    40997    37808
          102400    1024    37929    38104    41271    41499    41488    38119
          102400   16384    37099    38329    41796    41946    41958    38313
         1024000   16384    38249    38414    41976    41997

High sequential transfer speeds are only important for a few use cases (e.g. storing big files on a NAS) but for the majority of both use cases and people random IO performance is more important (and here every USB2 attached SSD outperforms every HDD, even SATA or SAS attached -- simply since spinning rust always sucks in this area and shows horrible low IOPS and high latency at the same time)

This whole UASP thing is new to me.  Thanks for helping me understand. 

 

Getting an accurate sense of how many MB/sec one can realistically expect has a huge impact on deciding on an SBC, IMHO.  This factors in huge to how fast a NAS will perform, and for desktop performance as well.

 

PS: I asked the Raspberry Pi foundation to add UASP to their next SBC, on their forum.  If anyone would like to chime in with me, here it is:

https://www.raspberrypi.org/forums/viewtopic.php?f=29&amp;t=125840&amp;p=1362880#p1362880

 

 

Share this post


Link to post
Share on other sites
3 hours ago, esbeeb said:

Getting an accurate sense of how many MB/sec one can realistically expect has a huge impact on deciding on an SBC, IMHO.  This factors in huge to how fast a NAS will perform, and for desktop performance as well

 

No, "MB/s" is 99% irrelevant for 'desktop performance'. You need fast random IO (IOPS) and low latency but MB/s only talks about sequential IO.

 

TL;DR: MB/s is interesting when you write and read large chunks of data in a sequential fashion (e.g. storing ISOs or movies on a NAS) but in general you need fast random IO (dealing with small chunks of data in a truly random fashion). A HDD on a real SATA port (capable of up to 150MB/s or even 200MB/s when it's an empty 3.5" one) will perform magnitudes lower if the OS is on it than any SSD behind an USB2 port (regardless of UAS or not). HDDs suck at random IO.

 

Random IO is important and sequential IO is close to irrelevant.

Share this post


Link to post
Share on other sites
1 hour ago, tkaiser said:

 

No, "MB/s" is 99% irrelevant for 'desktop performance'. You need fast random IO (IOPS) and low latency but MB/s only talks about sequential IO.

 

TL;DR: MB/s is interesting when you write and read large chunks of data in a sequential fashion (e.g. storing ISOs or movies on a NAS) but in general you need fast random IO (dealing with small chunks of data in a truly random fashion). A HDD on a real SATA port (capable of up to 150MB/s or even 200MB/s when it's an empty 3.5" one) will perform magnitudes lower if the OS is on it than any SSD behind an USB2 port (regardless of UAS or not). HDDs suck at random IO.

 

Random IO is important and sequential IO is close to irrelevant.

OK, so if I catch your drift (and please correct me if I'm wrong), then any Armbian-supported SBC which has the OS on an eMMC would give much better desktop performance, than, say, the OS being on a run-of-the-mill SD card, since presumably the eMMCs (such as the eMMC's which this board supports) would have nice, high fast random IO (IOPS) and low latency (even though the MB/s of the eMMCs might seem a little lack-lustre, at say, 40ish MB/s).

 

In other words, if you want to run a desktop on this board, then definitely use the eMMC for the OS (as the obvious way to get the easiest-to-set-up, best desktop performance).  Unless of course, the MicroSD card is one of the latest ones with the "A1" branding, or the really good Samsung EVO card on Amazon, mentioned in the Armbian Documentation.

Edited by esbeeb
mention evo microsd cards.

Share this post


Link to post
Share on other sites

Good news!

 

I ordered a bunch of copper shims of various sizes and heights last year on Aliexpress but had no clue where I put it. Found it yesterday evening and immediately gave it a try.

 

In the following I use a copper shim of 15x15mm in size and 0.8 mm height to connect heatsink and H5 SoC with a thin film of thermal compound. Since I fear shorting something around the SoC area I simply used the 1mm thermal pad I had left from my RockPro64 (after replacing it with a copper shim there too). It's super easy to cut these thermal pads so I simply did exactly this:

NanoPi_K1_Plus_and_efficient_heat_dissip

 

Now repeating the 'sbc-bench.sh -T 64 ; sbc-bench.sh -t 45' with the board in open enclosure lying flat on the surface (full output):

Throttling statistics (time spent on each cpufreq OPP):

1152 MHz:  273.18 sec
1104 MHz:   27.14 sec
1056 MHz:       0 sec
1008 MHz:       0 sec
 960 MHz:       0 sec
 912 MHz:       0 sec
 816 MHz:       0 sec
 648 MHz:       0 sec
 408 MHz:       0 sec

Let's compare with the thin thermal pad from above. Both tests with same improved thermal settings (starting to throttle at 75°C) it's pretty obvious to realize where the real problem is: between SoC and heatsink:

              thermal pad  copper shim
  1152 MHz:     76.09 sec   273.18 sec
  1104 MHz:     36.09 sec    27.14 sec
  1056 MHz:    165.10 sec        0 sec
  1008 MHz:     23.04 sec        0 sec
   960 MHz:         0 sec        0 sec

Thermal pads suck!

 

Interconnecting SoC and heatsink in a more efficient way (0.8mm copper) greatly improves heat dissipation from SoC to heatsink. And that's the culprit.

 

Edit: Repeated the test twice now with top cover assembled (fully enclosed). Two times since the PCB has its own thermal mass and air and components are expected to 'store' some heat over time:

                  open enclosure               with top cover
              thermal pad  copper shim      1st run      2nd run
  1152 MHz:     76.09 sec   273.18 sec     175.52 sec  163.46 sec
  1104 MHz:     36.09 sec    27.14 sec      72.72 sec   67.07 sec
  1056 MHz:    165.10 sec        0 sec      52.10 sec   69.81 sec
  1008 MHz:     23.04 sec        0 sec          0 sec       0 sec
   960 MHz:         0 sec        0 sec          0 sec       0 sec

 

So... tiny enclosures also suck! :)

 

But please keep in mind: sbc-bench is using cpuminer which makes heavy use of NEON optimizations. With more lightweight stuff like stress-ng, sysbench or 'full server load' my cooling setup is already sufficient to keep the SoC at above 1100 MHz even under full load. This is NanoPi K1 Plus in enclosure with 0.8mm copper shim between SoC and heatsink running 'sysbench --test=cpu --cpu-max-prime=200000000 run --num-threads=4' after 15 minutes:

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
12:59:35: 1152MHz  4.01 100%   0%  99%   0%   0%   0% 63.8°C  0/8
12:59:40: 1152MHz  4.00 100%   0%  99%   0%   0%   0% 63.4°C  0/8
12:59:45: 1152MHz  4.00 100%   0%  99%   0%   0%   0% 64.0°C  0/8
12:59:50: 1152MHz  4.00 100%   0%  99%   0%   0%   0% 63.8°C  0/8

 

Share this post


Link to post
Share on other sites
2 hours ago, esbeeb said:

any Armbian-supported SBC which has the OS on an eMMC would give much better desktop performance, than, say, the OS being on a run-of-the-mill SD card, since presumably the eMMCs (such as the eMMC's which this board supports) would have nice, high fast random IO (IOPS) and low latency (even though the MB/s of the eMMCs might seem a little lack-lustre, at say, 40ish MB/s).

 

Exactly. But...

  • All flash media will eventually wear out (we had reports of eMMC that died in the forum from users who were running a desktop Linux on the boards). So having socketed eMMC as it's the case here is great.
  • The better A1 rated SD cards are also a good alternative (e.g. SanDisk Extreme A1 or Extreme Plus A1). For details see (especially at the end of): https://forum.armbian.com/topic/954-sd-card-performance/
  • Browsers like Chromium constantly write to storage (updating caches and so called 'profiles'). So with the rootfs on slow storage this will impact performance a lot. That's why we in Armbian ship with psd (profile sync daemon) and keep Chromium's cache in RAM. Which is in itself a problem since then more RAM is used and the OS might start to swap earlier
  • Swap on SD card is a horrible thing and it's not that great on slow eMMC either. For this reason in Armbian we replace swap on storage with zram entirely (part of next major release)
  • There's still room for improvement, e.g. let Chromium store its caches in RAM also in compressed format. Work in progress and I won't look into it any further since I don't like 'desktop Linux' especially not on such slow devices like SBC

BTW: in RPi forum you wrote 'up to 170 MB/s' with USB3/UAS. This was bottlenecked by a 3.5"HDD. We get on capable boards with large block sizes up to 400 MB/s with USB3 and UAS: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&amp;comment=51350 (with 'true' SATA or NVMe of course a lot more).

 

And wanting UAS on those Raspberries is 100% pointless even if it would be just a CONFIG_UAS=y. Those Raspberries are not based on ARM SoCs but on something entirely different: VideoCore IV runs ThreadX as primary operating system. And then there are some crappily integrated ARM cores and there's only one single USB2 connection to the outside. Everything storage or networking (except wireless) is behind at least one internal USB hub (on their latest RPi 3 B+ when attaching stuff to the 'wrong' ports it's even TWO USB hubs in between) and always bottlenecked by this single USB2 connection to the SoC. You don't want a hub between host controller and USB storage, you don't want network and storage have to share the same bus (shared bandwidth and contention issues). So if you think about any use case that involves networking or storage the best way to deal with a Raspberry Pi is to simply avoid it and use something else that works magnitudes better/faster.

 

 

Share this post


Link to post
Share on other sites
10 hours ago, esbeeb said:

I asked the Raspberry Pi foundation to add UASP to their next SBC, on their forum.  If anyone would like to chime in with me, here it is:

https://www.raspberrypi.org/forums/viewtopic.php?f=29&amp;t=125840&amp;p=1362880#p1362880

 

And it happened what happens all the time if something critical is posted in the RPi forum: they censored it as usual. Only 8 words left from you as a quote. :) 

 

Please understand the behavior of the forum moderators. The majority are RPi Trading employees. They know their only product is outdated like hell (the VideoCore 4 is from 2010) and can't compete with any other modern SBC. More importantly their skills (dealing with the proprietary closed source VideoCore stuff) are literally worthless outside the little RPi world. So they're eagerly trying to keep their forum 'clean' and remove everything that could be distracting for their users. Clueless consumers is their only real asset. Users who do some research end up using other boards so they're lost for them anyway.

 

 

Share this post


Link to post
Share on other sites
12 hours ago, tkaiser said:

 

And it happened what happens all the time if something critical is posted in the RPi forum: they censored it as usual. Only 8 words left from you as a quote. :) 

 

Please understand the behavior of the forum moderators. The majority are RPi Trading employees. They know their only product is outdated like hell (the VideoCore 4 is from 2010) and can't compete with any other modern SBC. More importantly their skills (dealing with the proprietary closed source VideoCore stuff) are literally worthless outside the little RPi world. So they're eagerly trying to keep their forum 'clean' and remove everything that could be distracting for their users. Clueless consumers is their only real asset. Users who do some research end up using other boards so they're lost for them anyway.

 

 

Yikes, indeed they censored me.  I thought I was being polite.

 

Well, the one thing I really, really love about the Raspbery Pi, despite the admittedly technical outdatedness, is that they stand behind their product, such as it is, much more long-term than all the other SBC makers seem to.  They also hired Simon Long to work full time for several years running on polishing up the lightweight desktop of their choosing.  I really appreciate all his UX work, which virtually no other SBC makers seem to have the resources and/or desire to invest in: that 10% of polish on their end-user experience that makes a very big difference to all the average, less-technical, non-linux geeks of the world.  Every sharp edge they smooth out prevents the scaring away of new users who probably have very short attention spans, what with the smartphones that they're much more accustomed to being so dumbed-down for the masses.  Having said this, I think Armbian has also come a long way in smoothing out rough edges as well.

 

So based on the longer-term support, and praiseworthy UX people like Simon Long, I cut Raspberry Pi a lot of slack.  They're spreading Linux to a new generation far more effectively than most Linux-related projects out there!  All that PR they work hard at, is worth something positive in my books, in the grander scheme of things.

 

I fully agree that the use-case of anything storage-intensive, as not being suitable on the Pi.  But they deserve a honored place at the table of embedded computing, for what they've managed to accomplish so far, in the particular use-cases where they are much more suited.  So please cut them a little slack, @tkaiser.

Share this post


Link to post
Share on other sites
16 hours ago, tkaiser said:

Browsers like Chromium constantly write to storage (updating caches and so called 'profiles'). So with the rootfs on slow storage this will impact performance a lot. That's why we in Armbian ship with psd (profile sync daemon) and keep Chromium's cache in RAM. Which is in itself a problem since then more RAM is used and the OS might start to swap earlier

That's so cool.  I didn't know that.

Share this post


Link to post
Share on other sites
On 9/8/2018 at 6:00 AM, tkaiser said:

Thermal pads suck!

Yep.  I mentioned a while ago that I was amused by the giant one packaged with the NanoPi Neo.  At the same time I was using them for dumb music players, so not a lot of heavy lifting so I didn't care.  :lol:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0