• Content count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    tkaiser got a reaction from gounthar in Annoying fan noise on XU4   
    Buying a fast board to operate it slow is an option? Really?
    I would cap max frequency of the big cores from 2.0 GHz to 1.8 GHz or maybe 1.6GHz (/etc/default/cpufrequtils) and then check again. The upper DVFS operating points have to use a much higher voltage to get CPU cores working stable so the amount of heat the SoC dissipates at the top clockspeeds is much higher than slightly below.
    I would prefer a 5% or 10% performance drop instead of running slow all the time.
    And yeah, the fansink is a joke since not sufficient to provide appropriate cooling. With demanding workloads throttling will always occur (you can't run anything really heavy at 2.0 GHz with the fansink) and the sound is annoying.
    BTW: To diagnose and optimize behaviour running 'armbianmonitor -m' in a shell is always a good idea.
    In case the CPU cores run at high clockspeeds with ondemand even when idle this might be another occurence of 'sampling_rate' being inapppropriate with recent kernels.
  2. Like
    tkaiser got a reaction from Igor_K in NanoPi NEO4   
    Well, then I would prefer to use ODROID design since the NAS case for NEO/NEO2 unfortunately does not attach the SoC to the enclosure to efficiently dissipate heat away.
    (still waiting for someone designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports)
  3. Like
    tkaiser reacted to TonyMac32 in Tinkerboard S: What is ASUS view on voltage drops in cables?   
    @tkaiser I had something messing with the GPIO pins, after a good cleaning we're back to the proper function.  I hadn't tried it on the S yet, my early test board would shut down if you tried to power it via GPIO so I was overly suspicious I think.
  4. Like
    tkaiser reacted to TonyMac32 in Powering through micro USB   
    **UPDATE August 9 2018**
    After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity.  I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu  I apologize for the bad information)  Other small updates include a possible reason for the small voltage reporting measurement error.
    After having received an official Tinker Board Power supply, I submit my findings:
    Test load hardware:  Tinker Board S with internal voltage monitoring
    Condition:  No peripherals save mouse/keyboard/small cooling fan to prevent throttling
    Load:  minerd --benchmark
    Measurement:  For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work.  It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient.
    The Tinker S reads low when you get to the 5.0V area.  I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts.  This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load.  With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load.  
    As to the supply itself:
    Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire.
    5.0 V 3.0 A.  This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop. The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply. Data:

    Analysis/Commentary (very loose format):
    Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load)
    Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints.  It is experiencing excursions just below the acceptable minimum, so that will be something to look out for.  There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load.
    Recommendations for consumers: 
    This supply will work, and is at least on par with the other similar units on the market.  The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu.  Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work.
    Recommendation to ASUS: 
    If it is at all possible request the supplier increase the output voltage of this supply by 250 mV.  At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility. 
  5. Like
    tkaiser reacted to @lex in Trying to compile Pine H64   
    OrangePi One Plus BSP 4.9, kernel 4.9.56 stock for analisys. 
    Here is DRAM initialization in use (hope is what you meant):
    [271]PMU: AXP806 [275]set pll start [278]set pll end [279]rtc[0] value = 0x00000000 [282]rtc[1] value = 0x00000000 [285]rtc[2] value = 0x00000000 [288]rtc[3] value = 0x00000000 [292]rtc[4] value = 0x00000000 [295]rtc[5] value = 0x00000000 [298]DRAM VERSION IS V2_5 [300]PMU:Set DDR Vol 1200mV OK. [304]PMU:Set DDR Vol 1200mV OK. [314]BYTE0 GATE ERRO IS = 00000002 [318]BYTE1 GATE ERRO IS = 00000002 [321]BYTE2 GATE ERRO IS = 00000002 [324]BYTE3 GATE ERRO IS = 00000002 [336]DRAM CLK =744 MHZ [338]DRAM Type =7 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3) [343]DRAM zq value: 003b3bfb [350]IPRD=006f006e--PGCR0=00000f5d--PLL=b0003d00 [354]DRAM SIZE =1024 M,para1 = 000030fa,para2 = 04000000 [366]DRAM simple test OK. [369]dram size =1024 tinymembench, running first time with interactive governor:

    Running subsequent tinymembench with performance governor:
    Things you should consider in your analysis that could favor some results or not.
    * axp806 not detected by kernel
    [    0.431724] [axp806] chip id not detect 0xff ! [    1.496996] input: axp80x-powerkey as /devices/platform/soc/pmu0/axp80x-powerkey/input/input0 [    4.925539] axp80x_aldo1: unsupportable voltage range: 858992688-3300000uV * eth not functional
    [    0.816207] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:csi0 [    0.824909] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdc0 [    0.833599] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdio0 [    0.843450] gmac-power2: NULL [   11.600421] libphy: gmac0: probed And the usual:
    I am pretty sure it runs at 1.8 GHz:
    CPU1 freq      : 1800 MHz  CPU2 freq      : 1800 MHz  CPU3 freq      : 1800 MHz  CPU4 freq      : 1800 MHz  CPU count      : 4   Governor       : performance   SOC Temp       : 55 C  Next time i get results from 3.10...
  6. Like
    tkaiser reacted to @lex in Trying to compile Pine H64   
    I am running @Icenowy kernel, 1.5 GHz, 3.10.65 with some minor modification and 4.4.y 4.9.y without ethernet and axp805/6 not recognized .
    I will run  tinymembench possibly tomoorow (lack of time)...
  7. Like
    tkaiser reacted to Icenowy in Trying to compile Pine H64   
    BTW (off topic of this post) the NS1068 quirk in kernel cmdline can be dropped now, as it's mainlined by me.
    NS1066 one should still be kept as I didn't get a quirky NS1066 (my NS1066 just doesn't announce UAS).
  8. Like
    tkaiser reacted to gprovost in Benchmarking CPUs   
    @tkaiser Here the link of my latest benchmark of Helios4 :
    I get the following result for OpenSSL speed
    OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 1280.56k 5053.40k 18249.13k 52605.27k 102288.04k 109390.51k aes-128-cbc 1285.51k 5030.68k 18256.13k 53001.90k 100128.09k 109188.44k aes-192-cbc 1276.82k 4959.19k 18082.22k 51421.53k 96897.71k 103093.59k aes-192-cbc 1290.35k 4961.09k 17777.24k 51629.74k 95647.06k 102596.61k aes-256-cbc 1292.07k 5037.99k 17762.90k 50542.25k 92782.59k 98298.54k aes-256-cbc 1281.35k 5050.94k 17874.77k 49915.90k 93164.89k 98822.83k  
    In order to leverage on hw crypto engine, I had no choice but to use OpenSSL 1.1.1 lib (openssl-1.1.1-pre8) and I decided to use cryptodev-linux instead of AF_ALG since it gives me slightly better result (+5-10%).
    Here a bit of findings regarding OpenSSL engines implementation :
    As stated in the changelog
    Changes between 1.0.2h and 1.1.0 [25 Aug 2016] *) Added the AFALG engine. This is an async capable engine which is able to offload work to the Linux kernel. In this initial version it only supports AES128-CBC. The kernel must be version 4.1.0 or greater. [Catriona Lucey] So using Debian Stretch package OpenSSL 1.1.0f, or any more recent 1.1.0 version, the only cipher supported by AFALG engine was effectively AES-128-CBC
    $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC]  
    Starting OpenSSL 1.1.1, even though it is not mentioned anywhere in the changelog, AES192-CBC and AES256-CBC is supported by the AFALG engine
    $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC, AES-192-CBC, AES-256-CBC]  
    But one thing much more exiting about OpenSSL 1.1.1 is the following
    Changes between 1.1.0h and 1.1.1 [xx XXX xxxx] *) Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8.4 as well. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.h is assumed to exist on all of them. [Richard Levitte] So now with the 1.1.1 is pretty straight forward to use cryptodev, no need to patch or configure anything in openssl, openssl will detect automatically if module cryptodev is loaded and will offload crypto operation on it if presents.
    $> openssl engine -c (devcrypto) /dev/crypto engine [DES-CBC, DES-EDE3-CBC, BF-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-ECB, AES-192-ECB, AES-256-ECB, CAMELLIA-128-CBC, CAMELLIA-192-CBC, CAMELLIA-256-CBC, MD5, SHA1] (dynamic) Dynamic engine loading support  
    Based on those info, and making the assumption that sooner than later openssl 1.1.1 will be available in Debian Stretch (via backports most probably), i think the best approach to add openssl crypto engine support in Armbian is via the cryptodev approach. This way we can support all the ciphers now. I will look how to patch properly dpkg openssl_1.1.0f-3+deb9u2 to activate cryptodev supports. @zador.blood.stained maybe you have a different option on the topic ?
  9. Like
    tkaiser got a reaction from gounthar in Cheapest 64bits eMMC Gigabit Ethernet 1GB RAM supported board   
    I would never buy a S912 device. Pretty underwhelming 'performance' especially with single threaded applications that land on the wrong cores and the usual Amlogic cheating:
    And if you buy cheap TV boxes it shouldn't be surprising that components inside are also cheap. Same with SSDs BTW
  10. Like
    tkaiser got a reaction from gounthar in Cheapest 64bits eMMC Gigabit Ethernet 1GB RAM supported board   
    Rock64 (but their eMMC is neither super fast nor would I trust too much into it). Based on your other post the obvious choice is still Rock64 + their SATA cable + a great SSD.
  11. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    mSATA defines two sizes and both fit. Each JMS578 chip on the expansion board is just like an 'external USB disk' so all the information available talking about USB disks also applies to the situation here. If your Zero has SPI NOR flash and you manage to burn u-boot into it you can load everything else from USB. But this requires you doing some research and is not automated by nand-sata-install (what a stupid name these days).
    If there's something I would put my swap on it would be the fastest storage available (especially wrt random IO). On those USB2 boards without superfast eMMC that's always an UAS attached SSD.
    Compare here with there:
    Close to 3,000 4K IOPS with a good SSD behind a good USB-to-SATA bridge (like JMS578) behind an Allwinner USB2 port A SanDisk Extreme A1 SD card behind a standard (bottlenecked) DDR50 SDIO controller only scores ~1000/~2500 4K IOPS. It would need a better SDIO interface mode for better performance but that's nothing any of those cheap Allwinner boards provides On boards with super fast eMMC this is also an option. Recent Samsung 5.1 eMMC provides +7000 4K IOPS (see ODROID-N1 numbers -- you have to divide numbers through block size to translate from KB/s to IOPS) If you avoid cheap crap SSDs it's 100% save to use them since unlike SD cards or USB pendrives you can query them about their health and replace them before they finally die. The magic word is SMART:
  12. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Nope, using hdparm for 'benchmarks' is just fooling yourself. A 'benchmark' that lasts only 3 seconds is a joke. With hdparm you generate numbers without meaning. It's great to generate data but there's no information. And focusing on sequential reads only is strange anyway (since this is most probably not what you will ever do with your application later?).
    The 850 EVOs show excellect random write performance so why do you sacrifice an USB3 thumb drive to potentially slow your system down (is it swapping?)
    BTW: With mainline kernel sequential writes and reads will exceed 37 MB/s (maybe even more after increasing DRAM clockspeed) but I ran into the problem that for whatever reasons the JMS578 controllers on the board weren't detected as UAS capable (which is bad since it affects both sequential and random IO performance especially with SSDs).
  13. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    In the meantime FriendlyELEC provides something similar that is also much worse unfortunately:

    It's an Expansion Board for their NEOs with DC-DC converter and an enclosure. Looks nice but a few details are awful:
    According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice) This enclosure would've be the perfect choice to make use of NEO's design. Due to the SoC placement the enclosure could dissipate the heat to the outside by putting a simple thermal pad between SoC and enclosure. Putting a heatsink on NEO and both into an enclosure looks like a joke. On their product page (here or look at the picture above) you see that they talk about H3. Nasty since the H3 based NEO has only Fast Ethernet so it's a pretty bad choice for a NAS. The only NEO suitable for this use case fitting in that enclosure would be H5 based NEO 2. But on the other hand: if you're already bottlenecked by ultra slow network the crappy USB-to-SATA bridge doesn't matter any more. FriendlyELEC provides an OMV OS image ('OpenMediaVault' claims to 'make NAS easy', everytime I tried it performance was horribly low since the necessary parameter tuning hasn't been done -- I hope FriendlyELEC looked into this). This OS image is based on kernel 3.4.39! Are you kidding me? Why not mainline kernel for this? There's not a single reason to use a smelly Android kernel with this use case (no display and no audio) and especially not that outdated/unpatched 3.4.39 when there's a community patched 3.4.113 also available. I'm sure this thing will sell even if it will perform badly. And of course it's better than any Raspberry Pi based NAS but it's really sad that FriendlyELEC starts to target a clueless audience. If there would be a better USB-to-SATA bridge inside this thing combined with NEO 2 running mainline kernel and a custom OMV build that sets parameters correctly would make a great low-end NAS. Unfortunately we're talking about something different here
    Screenshot showing kernel version used on their OMV build:
  14. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    Well, on the first pages of the mainly mis-used 'Orange Pi Zero went to the market' thread there were some idle consumption numbers and everything else depends on usage. See difference between idle and 'full load' numbers for H3 here (and keep in mind that Zero default settings are for IoT and therefore low consumption) and add consumption of connected peripherals.
    My understanding is that powering the NAS Expansion board through the 4/1.7mm barrel plug should provide 3.3V/5V to a connected mSATA disk, 5V to the SATA power port and also the Zero where this voltage is also available at the power pins of the Type A receptacle (without the usual 500mA restriction of USB2 ports on 'real computers' but providing more -- still too lazy to check schematics whether there is some sort of current control or not). Using Xunlong's 5V/3A PSU should suffice to power board, a mSATA SSD and 2 2.5" disks (one connected to SATA + SATA power port, the other via USB).
    BTW: 3.5" disks with own PSU need just a small/cheap mechanical converter if the SATA port is already used:

    There's a SATA power connector on the board and adapter cables exist, eg.
    Please be aware that 4 vendors sell these cables but polarity of the 5V lines differs! See for details.
    Edit: Since Xunlong designed the original Banana Pi and used the same SATA connector on the first A20 based Orange Pi i would assume polarity of the SATA power connector to be compatible to the SATA cable kit they sell. But this needs to be confirmed!
  15. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    But not with this Expansion board since it seems (still no schematic available so also still no idea what the 2 USB type A jacks do exactly) SuperSpeed data pairs are not even routed to anywhere (I kept this as a test the whole time since until recently someone else constantly wrote around Zero and this Expansion board yelling 'USB3' without having the slightest idea what he was talking about).
    Regarding USB front ports connected via cables just do a web search for 'usb front ports unreliable' for example. I had one customer where the admins responsible for the PCs (the minority there, 270 Macs vs 150 PC) put a sticky on every PC they deployed: "Don't use USB front ports, only use those on the back". And a friend of mine who started with SBC recently wrote me after he failed to even boot Armbian and I recommended Etcher (verifying image burning!) that he realized that he can not use an USB3 card reader on his PC's USB3 front ports without corrupted data on SD card while on the back everything was fine. But using an USB2 card reader the front ports seem to be reliable.
    As usual: Expectations vs. reality. The average user has no clues about cable length, EMI, shielding but expects 5Gbps signaling working flawlessly even under worst case conditions (while it's not that easy, so let's not even think about this NAS Expansion board trying to make use of USB3 SuperSpeed )
    Edit: Almost forgot: Unshielded USB3 signaling is also great to interfere with 2.4GHz Wi-Fi band:
  16. Like
    tkaiser got a reaction from gounthar in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    '1080p video' is resolution but doesn't tell anthing regarding bitrates (depends on encoding/codec used). So you have to check how high bitrate requirements of your media files are. Please note: most people confuse codecs with file/container formats. If you have files lying around with names ending on .mp4 that still doesn't tell anything:
    The good news: bitrate requirements for most media formats are rather low so even Fast Ethernet should suffice (since this stuff is meant for streaming and the usual encoders are configured to not exceed a specific bitrate anyway -- in case 'the scene' needs higher bitrates than allowed the encoder partially decreases image quality to remain below the bitrate treshold).
    Fast Ethernet means 8 MB/s at least. With current cpufreq settings in Armbian images actual values might be lower since cpufreq might remain at the lower 240 MHz most of the time. Switching to performance governor might help:
    But even the 5 MB/s reported by @jimandroidpc should be sufficient for most media files (please remember that there are many Android TV boxes with only Fast Ethernet around and the bitrates that work reliably over crappy 2.4GHz Wi-Fi have to be even lower).
    I won't comment on RAID used with SBC since I did it too often already. TL;DR: RAID has nothing to do with 'data safety', this is only about availability (business continuity) and people constantly fool themselves with RAID (if you're interested in my opinions a web search for 'tkaiser crap raid availability' or something like that should help).
    Again: I really hope that Xunlong already prepared a new board with Gigabit Ethernet and Zero form factor since with current Zero the NAS Expansion board seems somewhat strange (the JSM578 is capable of SAT and therefore also SMART, supports TRIM/UNMAP and also UAS which is nice since Allwinner SoCs can make use of UAS even with USB 2.0 when running mainline kernel. Normally you find this feature only on USB3 capable devices). But JMS578's potential is wasted on a board with only Fast Ethernet and crappy Wi-Fi.
  17. Like
    tkaiser got a reaction from lanefu in sbc-bench   
    Hi all,
    sbc-bench is now on Github:
    I'll link from the README there to this thread for further discussion about the tool and proper benchmark methodology.
  18. Like
    tkaiser got a reaction from Igor_K in AML-S905X-CC (Le Potato) vs Odroid C2   
    Aliexpress and FriendlyELEC? Usually not a good idea unless you want to pay more for no reason: vs.
    Those Amlogic SoCs support ABFC so 'raw' memory bandwidth is not that much of an issue. Another comparison between S905 and S905X:
    In case it's not known already:
  19. Like
    tkaiser reacted to Icenowy in Trying to compile Pine H64   
    Thanks to help from Jernej, the magenta display issue is solved in U-Boot commit 79405999d7ee43f830825751b200d739b53f20f5 ("video: sunxi: de2/3: clear all BLD address space").
  20. Like
    tkaiser reacted to gprovost in Benchmarking CPUs   
    @zador.blood.stained I think there isn't any distro OpenSSL packages that is built with hardware engine support.
    Also, even if engine is installed, OpenSSL doesn't use any engine by default, you need to configure it in openssl.cnf.
    But you right about cryptsetup (dm-crypt), it uses AF_ALG by default. I was wondering why so much delta between my 'cryptsetup benchmark' and 'openssl speed' test on Helios4.
    I just did a test by compiling openssl-1.1.1-pre8 with the AF_ALG (... enable-engine enable-afalgeng ...) and here are the benchmark result on Helios4 :
    $> openssl speed -evp aes-xxx-cbc -engine afalg -elapsed
    type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 745.71k 3018.47k 11270.23k 36220.25k 90355.03k 101094.74k aes-256-cbc 739.49k 2964.93k 11085.23k 34178.05k 82597.21k 90461.53k  
    The difference is quite interesting, with AF_ALG it performs much better on bigger block size, but poorly on very small block size.
    $> openssl speed -evp aes-xxx-cbc -elapsed
    type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 44795.07k 55274.84k 59076.27k 59920.04k 59719.68k 59353.77k aes-256-cbc 34264.93k 40524.42k 42168.92k 42496.68k 42535.59k 42500.10k  
    System : Linux helios4 4.14.57-mvebu #2 SMP Tue Jul 24 08:29:55 UTC 2018 armv7l GNU/Linux
    Supposedly you can even have better perf with cryptodev, but I think Crypto API AF_ALK is more elegant and easier to setup.
    Once I have a cleaner install of this AF_ALK (or cryptodev), I will run sbc_bench and send you ( @tkaiser ) the output.
  21. Like
    tkaiser got a reaction from NicoD in Benchmarking CPUs   
    That's great since the purpose of this test is an overall estimate how performant the relevant board would be when doing 'server stuff'. If you click directly on the 7-zip link here then you get an explanation what's going on at the bottom of that page:
    In other words: as expected.
    Your use case with Blender is something entirely different and 7-zip scores are useless for this. Primarly for the reason that Blender involves floating point stuff (while 7-zip focuses on integer and low memory latency). It's as always about the use case
    If we look closely on the other results we see that S905 for example has an advantage with cpuminer compared to the rather similar A53 SoCs S905X and RK3328 (that perform rather identical with 7-zip for example). Maybe the root cause for cpuminer's better scores will also be responsible for better Blender results on S905 compared to other A53 SoCs? It needs a different benchmark and a lot of cross-testing with the real application to get an idea how to reliably test for your use case.
  22. Like
    tkaiser got a reaction from gounthar in rk3288 or rk3328 which is fastest?   
    Impossible to answer if you don't tell your use case.

    If the RK3288 claims to run at 1.8 GHz it's less than 1730 MHz in reality and until recently all Linux OS images for RK3328 were limited to 1.3 GHz. We changed this just recently in Armbian (nightlies) and enabled the '1.4 GHz OPP' (1380 MHz in reality) by default while with ayufan images you need to enable higher cpufreq OPP yourself.
    So usually it's 1726 vs. 1286 MHz which doesn't matter that much since
    as you pointed out the RK3288 uses high-end ARM cores while the RK3328 relies on slow A53 single-threaded peak performance of the RK3288 at '1.8 GHz' is ~1550 7-zip MIPS while RK3328 scores ~1000 at '1.4 GHz' sustained CPU performance with the RK3288 without huge heatsink (or fan) will pretty fast drop down to RK3328 levels or below. The RK3288 generates way more heat it's always about 'use case first' -- for a 'Desktop Linux' totally different performance metrics are important compared to the 'NAS use case' or when the board should serve as a VPN endpoint.
  23. Like
    tkaiser reacted to wtarreau in Benchmarking CPUs   
    What you can do is increase the 2nd argument, it's the number of loops you want to run. At 1000 you can miss some precision. I tend to use 100000 on medium-power boards like nanopis. On the clearfog at 2 GHz, "mhz 3 100000" takes 150ms. This can be much for your use case. It reports 1999 MHz. With 1000 it has a slightly larger variation (1996 to 2000). Well, it's probably OK at 10000. I took bad habits on x86 with intel_pstate taking a while to start.
    Maybe you should always take a small and a large count in your tests. This would more easily show if there's some automatic frequency adjustment : the larger count would report a significantly higher frequency in this case because part of the loop would run at a higher frequency. Just an idea.
    Or probably that you should have two distinct tools : "sbc-bench" and "sbc-diag". The former would report measured values over short periods, an the latter would be used with deeper tests to try to figure whats wrong when the first values look suspicious.
  24. Like
    tkaiser got a reaction from TonyMac32 in Benchmarking CPUs   
    In the meantime I built GCC 8.2 on Stretch on the NanoPC T4. Cpuminer now scores 10.27 kH/s on Debian Stretch when built with GCC 8.2 vs. 8.24 kH/s when built with Stretch's GCC 6.3.
    This is stuff I want to outline. How cheap it can be to get better performance by simply caring about software  
    To build a new GCC version on the machine I followed this recipe (last line important since cpuminer needs to be rebuild afterwards):
    GCCVer="7.3.0" # replace with "8.2.0" when wanting to use this version cd /usr/local/src wget${GCCVer}/gcc-${GCCVer}.tar.xz tar xf gcc-${GCCVer}.tar.xz && rm gcc-${GCCVer}.tar.xz mkdir build cd gcc-${GCCVer} ./contrib/download_prerequisites cd ../build ../gcc-${GCCVer}/configure make -j $(grep -c '^processor' /proc/cpuinfo) make install echo "/usr/local/lib64" >/etc/ ldconfig gcc --version [ -d /usr/local/src/cpuminer-multi ] && rm -rf /usr/local/src/cpuminer-multi (I did the first steps always on a RK3399 board, and then transferred the build directoy to a RK3328 board and executed the final steps starting with 'make install' there -- twice as fast)
  25. Like
    tkaiser reacted to NicoD in Benchmarking CPUs   
    OPi+2 Armbian Stretch