tkaiser

Another benchmark number using https://github.com/tkinjo1985/cpuminer-multi (prerequisit on Stretch: 'apt install libcurl4-openssl-dev libgmp-dev libgmpxx4ldbl libjansson-dev pkg-config zlib1g-dev'). I get 3.94 kH/s running on the CPU cores at 1392 MHz (no throttling). And 3.95 kH/s when switching both cpufreq and memory (dmc) governor to performance. As a reference RK3399: https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/?do=findComment&comment=49425 I hoped for some slightly better numbers due to faster DDR4 RAM here.

No difference in numbers when trying out tx_delay = <0x25>; rx_delay = <0x11>; So i hope we get DT overlays working to be able to test through all reasonable combinations soon. Without DT overlays this would require a huge amount of reboots Edit: as a reference Rock64 numbers: https://forum.pine64.org/showthread.php?tid=4668

Now I remember: 2 of 3 u-boot patches failed or generated a warning (size_support_ddr4.patch and add_fdtfile_dt_overlays.patch IIRC).

Hmm... at least reverting back to the original tx/rx delay settings might be worth a look. But am running out of spare time this week. Wrt DRAM timings and this dmc stuff I've not the slightest idea how this works (ayufan several times tried to educate me already about this but to no avail ) -- I only queried /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/trans_stat and got the numbers from there.

And here are the numbers after doing the below (for details see here): https://pastebin.com/raw/d61z7YY1 echo performance > /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/governor If I understood correctly the result was switching from 1024 timing to 1066: root@renegade:~# cat /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/trans_stat From : To :78600000080000000085000000093300000010240000001066000000 time(ms) 786000000: 0 0 0 0 1 0 1 800000000: 0 0 0 0 0 0 0 850000000: 0 0 0 0 0 0 0 933000000: 0 0 0 0 0 0 0 1024000000: 0 0 0 0 0 1 5985353 *1066000000: 0 0 0 0 0 0 903822 Total transition : 2 Wrt TX/RX delay adjustments here is a script made by ayufan to check through a specific range: https://github.com/ayufan-rock64/linux-build/commit/d32a459705afdcc43e2e3f129e9b37577bf13962 (also useful to learn how to use DT overlays with RK's 4.4 BSP kernel). The settings we currently use as follows: https://github.com/teacupx/build/blob/98100bf764235e153bb6ce6fe558fc3a06f4aa39/patch/kernel/rk3328-default/Add_dts_rk3328-roc-cc.patch#L735-L736 But the script doesn't work for whatever reasons.

Agreed, although there was a question about HDMI connected vs not. In my case it was connected. Will be good to see what is different. I allowed the board to clock at up to 1.4 GHz and now numbers look better: 7-zip scores at 3600 and tinymembench numbers are closer to @Da Xue's: https://pastebin.com/raw/fXS5yynq The iozone numbers (as expected up to 400 MB/s) below were made with an ext4 formatted Samsung EVO840 in an ASM1153 enclosure (to compare here numbers with NanoPC T4): random random kB reclen write rewrite read reread read write 102400 4 17990 29229 20183 19710 18707 25283 102400 16 53238 77145 64954 65276 64100 75384 102400 512 290307 325750 306785 316503 316440 314954 102400 1024 333578 343750 330396 341635 340211 340705 102400 16384 383959 387502 372153 384013 384206 389908 1024000 16384 401165 404221 380780 383637 When testing with iperf3 I got the usual 940 Mbits/sec in RX direction but only 845 Mbits/sec TX. So most probably TX/RX delays need a little adjustment. 'armbianmonitor -u' output: http://ix.io/1fIV

https://github.com/armbian/build/commit/5eaa80faa2b39e1237177dcbbd0aaedbd14c0818 should fix it on future images (for now /etc/defaults/cpufrequtils needs a modification). I believe for the individual boards the DT contents should determine cpufreq/dvfs details and our cpufrequtils settings allow for a reasonable maximum. Wrt your iozone numbers... did you ensure you were running at 1296 MHz then too (switching temporarly to performance governor)?

Which storage media did you test with iozone? Seems like @Da Xue has better settings: https://forum.armbian.com/topic/6772-tinymembench-on-renegade-roc-rk3328-cc-1gb/

No one here knows. So better monitor http://wiki.friendlyarm.com/wiki/index.php/Special:RecentChanges and wait for the M4 page appearing there.

You could also attach a NVMe SSD (but then you need either Firefly's adapter or you choose one of those few 42 mm long NVMe SSDs but need to check whether they support also key B). For whatever bizarre reasons Firefly engineers chose an M.2 key B slot which ensures that only 2 PCIe lanes are routed to the slot (wasting the other 2 lanes RK3399 has) ensures that you can't use key M cards without the adapter Most probably you end up with this thing anyway (for performance numbers look at ODROID-N1 review since for whatever bizarre reasons both Firefly and Hardkernel engineers chose to use an ASM1061 instead of an ASM1062 to ensure another PCIe lane is wasted).

The slot is PCIe only so SATA SSDs will never show up.

I would prefer 'speaking' names so renegade is IMO better than roc-???-cc. Soon there will be a "Renegade Elite" available based on RK3399... and renegade-rk3328 and renegade-rk3399 look almost the same. So maybe calling this now just renegade and the RK3399 board then renegade-elite?

According to this review https://youtu.be/mBSfb6vlfKo?t=6m37s the FLIRC case is a very poor performer compared to the 'Wicked Aluminium Raspberry Pi 3 Case'. There's also https://cogent.design but it seems they stopped their business of selling overpriced aluminium enclosures. And all those enclosures are expensive like hell and I would guess not exactly environmentally friendly due to the need to process huge aluminium blocks? Anyway: By putting the SoC on the right side of the PCB so that a simple metal plate + thermal compound/pad can be used to dissipate heat away all of this stuff is not necessary any more...

This is by design on all ARM boards for the simple reason that activating monitoring results in permanent writes to the rootfs and if this is on flash media (SD card) Write Amplification is huge and the card will die way earlier. So if you want nice looking (but pretty useless) graphs simply activate monitoring and be prepared for your SD card failing early. Or move the rootfs to other storage (which has other downsides, eg. a HDD not spinning down any more when idle) I tried to explain the problem wrt Write Amplification already: https://forum.armbian.com/topic/6635-learning-from-dietpi/?tab=comments#comment-50489 https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/?do=findComment&amp;comment=50833

By default Pishrink will even resize the image to the maximum (which is IMO not the best strategy) at next boot: https://github.com/Drewsif/PiShrink/blob/8aae06a4b20b1638237e4a5442a26ebb3fe6a3b1/pishrink.sh#L11 (you need to call the script with -s to skip auto resize at next boot). Disclaimer: I've neither used the script before nor know how good it copes with all partitioning schemes Armbian supports (when it's targeting the Raspberry Pi then the script's assumption will be '1 FAT partition followed by 1 ext4 partition' while with Armbian it's completely different) In Armbian we do the resize never to full capacity but 'waste' 5% on SD cards of 4GB in size (or smaller), 2% with up to 8 GB and 1% above. The reason is to allow people to clone cards to another one 'of same size' (but two cards 'of same size' from different manufacturers never have the same capacity but differ slightly) and to help old/crappy cards with wear leveling (that's the 'leave a 5% spare area on old/small SD cards' rule explained above). BTW: The above commands also work after shutting down the board. Simply execute them followed by a reboot and you're done. BTW 2: All occurrences of resize2fs here in the forum are soon worthless since the service will be called armbian-resize-filesystem in the future. Same with firstrun which will be called armbian-firstrun. Of course all of this is stuff for our documentation but for whatever reasons contributions to Armbian are only declining...

Different location now: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption It's possible to decompile/manipulate/recompile DT files but at least I do not plan on porting the tool to mainline. With mainline you better go with DT overlays and the stuff many people are interested in (limit count of CPU cores and networking options) is done in /etc/rc.local anyway. And some stuff like changing DRAM clock speed simply doesn't work with mainline at all.

Since it's an Electron app (they're platform independent and all somewhat bloated). Anyway: recommending burning tools other than those that do a verify (to my knowledge only Etcher and Hardkernel's Win32DiskImager) is horrible! Inexperienced and first time users suffer from crappy SD cards and card readers and by telling them to use something different than Etcher is wasting their time and ours (since we get complaints about 'Armbian not booting' that are in reality just 'burning went wrong').

Does this tool always verify burning results? Does this tool always verify burning results? Does this tool always verify burning results? We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically. A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place. Recommending any burning tool that does NOT a verify the result by default is a really bad idea.

Just curious: why this? I always thought 20V are only needed when PD profiles 4 (60W) or 5 (100W) are needed. For profile 5 more expensive USB-C cables are needed and I already question the need for 60W 'somewhat'. Wouldn't be profile 3 with 36W be enough? Or will you also provide a mezzanine for full sized PCIe cards?

The 85°C were obviously a throttling treshold (simple software/DT setting). The more important part was that RK3399 without any cooling improvements (just the standard heatspreader) at this temperature can generate 6.6 khash/s with cpuminer and that big cores throttled down to ~900 MHz (another setting). This was just utilizing CPU cores (with demanding NEON code though) and RK3399 also has a capable GPU inside. With that large metal thing @Da Xue will prevent throttling for sure in normal environmental conditions. And since he said this is a design suitable for other boards to follow maybe there's also some safety headroom (no idea how much power for example an RK3399 Pro with CPU, GPU and NPU stuff will waste and how much heat it will generate)

I know these things well but as already said: With RK3399 it's simply not necessary. This huge pile of metal will be sufficient to prevent throttling if cpuminer on an ODROID N1 without any heatsink and active cooling at all can generate 6.6 khash/s and still stays below 85° C. I also tried this with a Banana Pro (SoC on the right side!) screwing it into a simple small Aluminium box with a thermal pad between SoC and metal enclosure. 8°C less in idle and the whole box got somewhat warm. And the thickness of the enclosure is just 0.8mm. The thermal mass of @Da Xue's metal brick is way higher.

Funny sharing of assumptions and opinions here. This stuff can be tested. And (not so) surprisingly it has already been tested: "In my tests I found it a bit surprising that position of the heatsink fins doesn't matter that much (one would think with heatsink fins on top as shown on the right above reported temperatures would be a lot lower compared to the left position but that's not the case -- maybe 1°C difference" The RK3399 doesn't generate that much heat anyway (especially compared to overheating candidates like RK3288 on Tinkerfurnace or the Exynos on Furnace XU4) Attaching the SoC surface with thermal compound or a pad to any large metal thingy (e.g. rack cabinets) works pretty well

You believe the thread starter used only a HDD? What about reading the threads you're writing to? Why should it? Why do people not read the threads they're writing too? It's explained in top post here why this device is problematic: powering is a problem, user expectations due to false advertising are a problem, software support situation is a huge problem since vendor offerings are crap and linux-sunxi community tries to get these R40/V40 boards mainlined for whatever reasons are way behind. It's also explained why this board will be a support nightmare since only bought by clueless users and blaming Armbian later for the hardware flaws like this crappy Micro USB connector to power it.

+50 SBC. 2 'failures' I can remember so far: Spring loaded SD card slot on a Raspberry Pi 2 broken (then using a bar clamp to hold the SD card into place) Somewhat strange behaviour on one Orange Pi One I tried to fry since 'powering through GPIO header' without noticing that the thing is 180° rotated. @zador.blood.stained is the OPi One still living I sent to you 2 years ago?

Today nobody (outside Hardkernel) knows for sure whether they use S922 (other SoC vendors like HiSilicon exist also) and nobody (outside Amlogic) knows for sure which CPU cores are inside S922