esbeeb Posted September 6, 2018 Posted September 6, 2018 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."
ag123 Posted September 6, 2018 Posted September 6, 2018 wow that heatsink is impressive, i'd make an attempt to drive for 2ghz if i have that
ag123 Posted September 6, 2018 Posted September 6, 2018 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 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
@lex Posted September 6, 2018 Posted September 6, 2018 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>; }; }; }; };
esbeeb Posted September 8, 2018 Posted September 8, 2018 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&t=125840&p=1362880#p1362880
esbeeb Posted September 8, 2018 Posted September 8, 2018 (edited) 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 September 8, 2018 by esbeeb mention evo microsd cards.
ag123 Posted September 8, 2018 Posted September 8, 2018 oh wow, that copper shim experiment is enlightening, thanks
esbeeb Posted September 9, 2018 Posted September 9, 2018 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.
esbeeb Posted September 9, 2018 Posted September 9, 2018 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.
TonyMac32 Posted September 9, 2018 Posted September 9, 2018 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.
nradulovic Posted June 13, 2019 Posted June 13, 2019 What happened to this topic? Why are tkaiser posts deleted?
Recommended Posts