Quick Review of NanoPi K1 Plus

Recommended Posts

Donate and support the project!

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."

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


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>;


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:




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.
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.

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.