Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Posts posted by tkaiser

  1. On 3/5/2019 at 9:51 PM, NicoD said:

    What do you think about the rest?

     

    I've a background in graphic design so I'm pretty sure you don't want to hear the answer. Small hint: it reminds of the 'golden age' of DTP 30 years ago.

     

    3 hours ago, NicoD said:

    It's up to Igor to decide

     

    This pretty much sums up what Armbian is.

  2. 17 minutes ago, dispo said:

    it felt like the version info in the banner was useful info when connecting to a box

     

    Well, why providing correct information if the main goal is just to print some fancy stuff on the screen? The whole motd (login greeting) stuff is broken since ever, in the past it delayed login by insane amounts of time, now it simply displays wrong information but as usual one person doesn't give a shit: https://github.com/armbian/build/pull/1129 (how to deal with years of ignorance? Better stay away from such a waste of time).

  3. 2 hours ago, lanefu said:

    I was wondering if there would be interest in replacing the armbianmonitor -r rpimontor  with it

     

    Only if you love monitoring mistake N°1: your monitoring is that heavy that it affects the way your system behaves. The purpose of RPi Monitor is to explore system behavior, e.g. adjust tunables to get sufficient ondemand governor behavior (which is broken on several platforms now but literally no one cares since all remaining devs are busy adding new devices and fancy features). If your monitoring is that heavy that your system will constantly clock at the upper speeds how would you be able to draw reasonable conclusions?

     

    Just like you should benchmark every benchmark you're using you should monitor your monitoring solution of choice (quite simple with armbianmonitor -m). Checking out netdata 3 years ago led to the above conclusions when testing on weak SBC.

     

    Also SBC stuff like CPU temperature and cpufreq scaling is missing. Netdata will show you CPU utilization only since it's meant for servers that will run on highest clockspeeds all the time. Which SBC is more busy: the one reporting 10% CPU utilization clocking at 1200 MHz or the one reporting 20% remaining at 480 MHz. Netadata's output is useless on systems with cpufreq scaling. It's only great for servers and for operators who know what they're doing. As such it should never be too easy to install it.

     

    For those people interested. You can play around with it on ODROID bench: https://forum.odroid.com/viewtopic.php?f=29&t=32257#p246987 (please keep in mind that the four instances are S922X installations and this SoC is as capable as Intel Atom designs. Far more capable than the average SBC Armbian supports)

  4. 3 hours ago, Stuart Naylor said:

    Chrome OS & Android use a single device and if you think about it

    Why do you ignore the answers you get? I explained that Armbian is not supposed to run only on one device but on many. And some of them still run with kernel 3.4. As such do we use up to 4 zram devices. More zram devices than 1 is needed on old kernels and doesn't matter on newer kernels (tested various times, simply search for zram).

  5. 3 hours ago, Stuart Naylor said:

     I have to ask if a zram device can accept multiple streams then why are we creating a device per core?

    You miss that Armbian still supports devices running with a 3.4 kernel. And obviously you also miss all of the research already done (use forum search) and how Armbian's implementation currently works (for example choosing the most efficient algo automagically depending on kernel capabilities for the log2ram partition)

  6. 2 hours ago, NicoD said:

    I don't believe in benchmaking, I've showed most/all benchmarking is off. But still I need to do it, and I hate it.

     

    Benchmarking is great! You simply fire up a bunch of tests in uncontrolled manner without monitoring what's happening, then generate bar charts out of the generated numbers and can then show that your devices are the fastest SBC around (even faster than those expensive NVIDIA Jetson thingies!!1!1!!):

     

    PTS-ODROID-N1-vs-N2.png

     

    (full results)

     

    Only problem: these bar charts above create the impression ODROID-N1 would be faster than N2 which is something Hardkernel clearly wants to avoid. Last year they cancelled their RK3399 based N1 for three reasons (two of them their customers don't want to hear) so they need to choose a bunch of benchmarks where N2 looks like an improvement compared to N1 and this pretty much explains why they only chose multi-threaded CPU benchmarks since with single-core stuff RK3399 usually is as fast as S922X or even slightly faster (this whole CPU benchmarking crap boils down to exactly this: S922X wins over RK3399 with multi-threaded loads while single-core stuff is usually faster on RK3399. Whether this is important or not always depends on the use case only. Majority of users staring at CPU benchmark charts simply don't understand that the relevant stuff happens somewhere else than stupid multi-core '100% CPU utilization' tests)

     

    So how to benchmark properly: if you're coming from the developer/researcher perspective then you need Active Benchmarking. All this kitchen-sink stuff is pretty useless. And then you do not benchmark to show how product A is faster than B but to get B as fast as A or even faster.

     

    From a user or consumer point of view it's always 'use case first'. Let's take your 'Blender' test here since this is also a real use case you're interested in (rendering stuff on slow SBC for whatever reasons). I mentioned Blender using SIMD Extensions only on x86 for a reason: to illustrate that if you're not a developer able to code and familiar with NEON2 on ARM you might be better off looking at x86 instead. The Gemini Lake thing on ODROID H2 for example is not equipped with Intel's latest and greatest extensions like AVX but at least fully supports SSE2 so maybe @rooted is so kind providing you with Blender numbers from H2? Maybe then your excitement for N2 is already gone and you're a future H2 buyer?

     

    Your stuff (a rather special application making use of special instructions) is an exception so how should benchmarks that test entirely different stuff show what's going on? You can't appropriately benchmark without knowledge and without being focused on the use case. Otherwise you're all the time just collecting numbers without meaning.

     

    Here I won't comment on why further contributing to Armbian (or using this forum) doesn't make that much sense for me but you should be aware that https://www.cnx-software.com is a great source of knowledge (especially in the comments section where insiders share details and experts explain so much stuff like how/why A72 and A73 differ and so on)

     

     

     

  7. 1 hour ago, Igor said:

    If installing packages from https://packages.debian.org/buster/proftpd-basic (+ this app dependencies) solves this problem, we can put them to our repository.

     

    Unbelievable.

     

    2 hours ago, esbeeb said:

    Note the current version in Armbian is still 1.3.5b.

     

    Nope, Armbian has no such package. Armbian is just a build system producing OS images based on some Debian or Ubuntu variants even if @Igor constantly tries to hide this by advertising Armbian as 'the best OS for SBC'. You're dealing with plain Debian here and if you found a bug you should report it upstream there. If you want a more recent Debian package version you should search backports repo first and if there's nothing try it with apt pinning.

     

    @Igorundermining stability of the package system in general by pulling in Buster packages into a Stretch repo is... I miss words... I mean what's the reason to rely on Debian's package system? What's the reason to rely on 'everything outdated as hell' AKA Debian in the first place? Isn't it the promise of 'stable' and the benefits of relying on a strong team of maintainers? It really looks like Armbian is still moving into a direction where anyone interested in STABLE operation ist lost :( 

  8. 13 hours ago, NicoD said:

    The better result of the RockPi4B could be because of this. So then the default CONFIG_HZ could have changed between 2 - 4 months for Bionic(guess).
    I'll know when I'm finished with the RockPi4B

     

    No, you do NOT know when you're finished firing up your next round of passive benchmarking tests spitting out some numbers. You need to know what's going on to generate answers to the question 'why is A faster than B' and also 'what is the limiter on A and why can't A not be twice as fast'? You missed this change and attributed faster RockPi scores to DDR4 vs. DDR3 memory while in reality you compared old Armbian kernel config with newer one. This whole passive benchmarking approach (and IMO 'technical' Youtube videos in general) always only contributes to confusion and generates zero insights.

     

    The general rule of passive benchmarking and what in fact happened here is: you benchmark A, but actually measure B, and conclude you've measured C (what's needed instead is Active Benchmarking)

     

    What matters are insights, settings and software. And this not only applies to RK3399 but to N2/S922X too of course. So with your use case that utilizes all CPU cores in parallel you surely should go with S922X (since being definitely faster than RK3399 with everything that's multi-threaded), then use a kernel with CONFIG_HZ=100 and an optimized software stack. With Gentoo for example, most recent GCC, optimal/aggressive compiler flags for the A53/A73 combo and a CONFIG_HZ=100 kernel on the N2 your Blender job might finish in less than 40 minutes (maybe just 20 or even less if a programmer equipped with knowledge starts to look into Blender code and adds NEON optimizations to the performance critical code parts -- see here for a great example of Active Benchmarking and adding NEON optimizations on ARM to a software that utilizes SIMD Extensions only on x86 so far just like SSE2 optimized Blender does)

     

    The price you'll pay is a few weeks of your life needed to become a Linux expert since there's nothing ready. Choosing Armbian is usually a matter of convenience but if you want software that performs as fast as possible it's a problematic choice since the software stack is not meant to be performant but to be compatible and stable (funny joke since Armbian's own approach with kernel/bootloader updates is the opposite). The two distro variants Armbian provides are

    • Ubuntu also known as 'everything outdated'
    • Debian also known as 'everything outdated as hell'

    (there are areas where Armbian is in fact faster than other Ubuntu/Debian based images or distros using a more modern software stack like Gentoo or Fedora but this is due to what separates Armbian from the stock Debian/Ubuntu stuff: settings like CPU/IRQ affinity, thermal/DVFS tuning, zram, log2ram and such stuff. But two guys who mostly took care of this contributed nothing to Armbian for a longer time now and no idea how Armbian evolves here in the future. On EoL platforms like Allwinner H5 IRQ affinity is already broken but nobody cares)

     

  9. 26 minutes ago, NicoD said:

    just done my first Blender test with the M4. 1h08m23s. +5 minutes faster than my previous tests. In the margines of your test. (1 minute difference is no difference...)

     

    Another thing to consider: SoC temperature. Even if no throttling happens higher temperature will result in both slightly lower performance and slightly higher consumption (details). With a task running over an hour SoC temperature 20°C vs. 70°C might result in ~1 minute difference (maybe even more -- at least that's another reason why sbc-bench always does temperature monitoring and this also explains why N2 benchmarks currently running on "ODROID bench" in a container but with active cooling seem to be faster compared to running bare metal with passive cooling only at higher temperatures).

     

  10. 24 minutes ago, NicoD said:

    That's another thing I have to add to "reasons why benchmarks can be misleading".

     

    There's a lot more. I just updated my post above with GCC 8.2 results. When Blender is built with a more recent compiler rendering gets faster (this is one of the many reasons why this Phoronix stuff is so bad -- Michael Larabel doesn't educate his users about such basics but throws a bunch of meaningless numbers and graphs at them to create the impression benchmarking would be something magic).

     

    And if you build Blender from source with appropriate compiler flags (not those ultra conservative distro defaults, especially not with 'stable' distros like Debian and Ubuntu) then it will be even faster.

     

    27 minutes ago, NicoD said:

    OPi3 ... it seems to underperform to the Rock64, OdroidC2

     

    Very unlikely. And performance is already known, check sbc-results for PineH64 (board vendors don't matter, it's only about the SoC in question). And of course settings matter. If you use one of those crappy Xunlong images there's no need to test further since they're known for using crappy Allwinner defaults that suck.

  11. 13 minutes ago, rooted said:

    The stock N2 kernel is running at CONFIG_HZ=250 so this is what my BMW benchmark was using.

     

    It's not a new setting, it's been around for a long time

     

    'Around for a long time'? The point is not since when settings exist but what the defaults are and why people interested in maximum performance should care about such settings. This was the context:

     

    All the RK3399 'benchmark' results collected so far were done with CONFIG_HZ=1000 (good for a responsive UI in Android and Linux, not so good for normal computing or server tasks) while everywhere around CONFIG_HZ=250 is the default. Is this affecting Blender or not? Anyone tested so far (latest ayufan images switched to CONFIG_HZ=250)?

     

    And by looking at both tinymembench and Blender scores it should be pretty obvious that this makes a difference for workloads that utilize CPU cores fully... just to explain why comparing RK3399 and S922X benchmark scores doesn't make that much sense as long as such essential stuff is not also considered.

     

    @NicoD: I explained in my former post how to check for such settings, simply check the spoiler.

  12. 10 minutes ago, balbes150 said:

    In RK, with an increase in the frequency of the processor (ceteris paribus), the result changes significantly, indicating a real increase in frequency (system performance)

    Same with S922X, simply check @rooted's sbc-bench results (where even the cpufreq OPP are checked and confirmed). The problem is not thermal but reliability/undervoltage due to the firmware running on the Cortex-M3 controlling DVFS which can be clearly seen by running the most heavy load called cpuminer. 

     

    Quoting myself: ''Overclocked' executions with both CPU clusters set to 2.0 GHz showed reliability issues most probably due to DVFS undervoltage (cpuminer quit almost immediately here while it ran only 50 seconds there -- this tool since being a load generator checking for data corruption can also be used for reliability testing but I would prefer our StabilityTester instead)'

     

    I already suggested to Justin and Dongjin to take our StabilityTester approach to provide N2 users with an easy way to check for undervoltage/instabilities since a lot of those users will activate the 'overclocking' settings (most probably these are undervolting settings at the same time based on results) and then end up with silent data corruption and/or crashes (all the great results of trying to get laughable 7%-8% performance gain almost nobody is able to notice).

     

    45 minutes ago, NicoD said:

    Could you explain to the ignorant (me) what exactly this does?

     

    Simply do a web search for CONFIG_HZ :)

  13. Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:

    • RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31
    • RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59
    • RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11

     

    That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.

     

     
    
    RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31
    
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              37.36    0.00    2.82    0.60    0.00   59.22
              97.34    0.00    2.26    0.00    0.00    0.41
              97.45    0.00    2.25    0.00    0.00    0.31
              97.48    0.00    2.21    0.00    0.00    0.31
              97.44    0.00    2.22    0.00    0.00    0.34
              97.23    0.02    2.44    0.00    0.00    0.32
              97.28    0.00    2.39    0.00    0.00    0.33
              97.32    0.01    2.33    0.00    0.00    0.34
              97.40    0.00    2.22    0.00    0.00    0.38
              97.33    0.01    2.18    0.00    0.00    0.49
              97.38    0.00    2.29    0.00    0.00    0.33
              97.29    0.00    2.33    0.00    0.00    0.38
              97.32    0.00    2.32    0.00    0.00    0.36
              97.40    0.00    2.29    0.00    0.00    0.31
              97.47    0.01    2.24    0.00    0.00    0.28
              97.34    0.00    2.35    0.00    0.00    0.31
              97.34    0.00    2.37    0.00    0.00    0.29
              97.39    0.00    2.29    0.00    0.00    0.32
              97.46    0.00    2.26    0.00    0.00    0.28
              97.61    0.00    2.11    0.00    0.00    0.28
              97.38    0.00    2.30    0.00    0.00    0.32
              97.22    0.00    2.40    0.00    0.00    0.38
              97.47    0.00    2.20    0.00    0.00    0.33
              97.45    0.00    2.24    0.00    0.00    0.31
              97.52    0.00    2.15    0.00    0.00    0.33
              97.36    0.00    2.27    0.00    0.00    0.37
              97.39    0.00    2.33    0.00    0.00    0.28
              97.28    0.00    2.24    0.00    0.00    0.48
              97.53    0.00    2.16    0.00    0.00    0.30
              97.45    0.00    2.19    0.00    0.00    0.35
              97.54    0.00    2.16    0.00    0.00    0.30
              97.39    0.00    2.28    0.00    0.00    0.33
              97.40    0.01    2.21    0.00    0.00    0.39
              97.50    0.00    2.16    0.00    0.00    0.34
              97.67    0.00    1.98    0.00    0.00    0.35
              97.54    0.00    2.10    0.00    0.00    0.36
              97.33    0.00    2.23    0.00    0.00    0.43
              97.40    0.00    2.30    0.00    0.00    0.30
              97.47    0.00    2.15    0.00    0.00    0.37
              97.60    0.00    2.09    0.00    0.00    0.31
              97.54    0.00    2.14    0.00    0.00    0.32
              97.61    0.00    2.13    0.00    0.00    0.26
              97.51    0.00    2.15    0.00    0.00    0.35
              97.48    0.00    2.16    0.00    0.00    0.36
              97.45    0.00    2.22    0.00    0.00    0.33
              97.34    0.00    2.32    0.00    0.00    0.34
              97.61    0.00    2.10    0.00    0.00    0.30
              97.37    0.00    2.34    0.00    0.00    0.30
              97.32    0.00    2.37    0.00    0.00    0.30
              97.40    0.00    2.25    0.00    0.00    0.34
              97.46    0.00    2.23    0.00    0.00    0.31
              97.45    0.00    2.20    0.00    0.00    0.36
              97.49    0.00    2.18    0.00    0.00    0.34
              97.34    0.00    2.35    0.00    0.00    0.31
              97.41    0.00    2.32    0.00    0.00    0.27
              97.42    0.00    2.25    0.00    0.00    0.33
              97.49    0.00    2.23    0.00    0.00    0.28
              97.51    0.00    2.15    0.00    0.00    0.34
              97.52    0.00    2.17    0.00    0.00    0.31
              97.42    0.00    2.24    0.00    0.00    0.34
              97.42    0.00    2.26    0.00    0.00    0.31
              97.47    0.00    2.16    0.00    0.00    0.37
              97.52    0.00    2.19    0.00    0.00    0.29
              97.55    0.00    2.08    0.00    0.00    0.37
              97.36    0.00    2.30    0.00    0.00    0.34
              97.60    0.00    2.03    0.00    0.00    0.36
              97.56    0.01    2.05    0.00    0.00    0.39
              97.74    0.00    1.99    0.00    0.00    0.28
              97.63    0.00    1.93    0.00    0.00    0.44
              97.57    0.00    2.14    0.00    0.00    0.29
              97.63    0.00    2.03    0.00    0.00    0.34
              97.65    0.00    2.03    0.00    0.00    0.32
              97.40    0.00    2.20    0.00    0.00    0.39
              98.03    0.00    1.63    0.00    0.00    0.34
              97.66    0.00    2.03    0.00    0.00    0.30
              50.37    0.00    2.53    0.00    0.00   47.09
               4.41    0.00    3.20    0.00    0.00   92.40
               
    root@rockpro64:~# zgrep CONFIG_HZ /proc/config.gz
    # CONFIG_HZ_PERIODIC is not set
    # CONFIG_HZ_100 is not set
    # CONFIG_HZ_250 is not set
    # CONFIG_HZ_300 is not set
    CONFIG_HZ_1000=y
    CONFIG_HZ=1000
    
    
    
    
    
    
    
    RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59
    
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               0.48    0.00    0.30    0.01    0.00   99.21
              65.25    0.00    0.75    0.01    0.00   33.99
              99.24    0.00    0.52    0.00    0.00    0.24
              98.99    0.00    0.54    0.00    0.00    0.46
              98.89    0.00    0.55    0.00    0.00    0.56
              98.74    0.00    0.59    0.00    0.00    0.66
              98.97    0.00    0.57    0.00    0.00    0.46
              99.07    0.00    0.53    0.00    0.00    0.40
              99.11    0.00    0.51    0.00    0.00    0.38
              98.80    0.00    0.57    0.00    0.00    0.63
              98.95    0.00    0.53    0.00    0.00    0.52
              98.87    0.00    0.60    0.00    0.00    0.53
              99.00    0.00    0.53    0.00    0.00    0.47
              99.04    0.00    0.51    0.00    0.00    0.46
              98.95    0.00    0.55    0.00    0.00    0.50
              98.91    0.00    0.57    0.00    0.00    0.52
              98.99    0.00    0.54    0.00    0.00    0.47
              99.07    0.00    0.59    0.00    0.00    0.34
              99.00    0.00    0.50    0.00    0.00    0.50
              98.98    0.00    0.55    0.00    0.00    0.47
              98.87    0.00    0.60    0.00    0.00    0.53
              99.00    0.00    0.58    0.00    0.00    0.41
              99.00    0.00    0.52    0.00    0.00    0.48
              98.96    0.00    0.55    0.00    0.00    0.48
              99.04    0.00    0.52    0.00    0.00    0.44
              99.10    0.00    0.56    0.00    0.00    0.34
              99.05    0.00    0.50    0.00    0.00    0.45
              99.07    0.00    0.50    0.00    0.00    0.43
              98.98    0.00    0.53    0.00    0.00    0.49
              99.15    0.00    0.48    0.00    0.00    0.36
              98.93    0.00    0.55    0.00    0.00    0.51
              99.06    0.00    0.54    0.00    0.00    0.40
              98.98    0.00    0.53    0.00    0.00    0.49
              98.90    0.00    0.60    0.00    0.00    0.50
              99.10    0.00    0.49    0.00    0.00    0.41
              99.02    0.00    0.54    0.00    0.00    0.44
              98.97    0.00    0.58    0.00    0.00    0.45
              99.00    0.00    0.55    0.00    0.00    0.45
              98.93    0.00    0.57    0.00    0.00    0.50
              99.07    0.00    0.51    0.00    0.00    0.42
              99.05    0.00    0.51    0.00    0.00    0.44
              99.04    0.00    0.56    0.00    0.00    0.40
              98.90    0.00    0.56    0.00    0.00    0.53
              98.92    0.00    0.56    0.00    0.00    0.52
              99.05    0.00    0.50    0.00    0.00    0.45
              98.94    0.00    0.58    0.00    0.00    0.49
              98.96    0.00    0.55    0.00    0.00    0.49
              98.83    0.00    0.56    0.00    0.00    0.60
              99.07    0.00    0.50    0.00    0.00    0.43
              98.89    0.00    0.56    0.00    0.00    0.55
              98.98    0.00    0.54    0.00    0.00    0.48
              99.11    0.00    0.49    0.00    0.00    0.39
              98.97    0.00    0.55    0.00    0.00    0.48
              99.05    0.00    0.54    0.00    0.00    0.41
              99.07    0.00    0.54    0.00    0.00    0.39
              99.02    0.00    0.51    0.00    0.00    0.47
              98.93    0.00    0.55    0.00    0.00    0.52
              98.83    0.00    0.54    0.00    0.00    0.63
              99.00    0.00    0.53    0.00    0.00    0.48
              99.03    0.00    0.47    0.00    0.00    0.50
              98.93    0.00    0.53    0.00    0.00    0.55
              99.05    0.00    0.47    0.00    0.00    0.48
              98.84    0.00    0.57    0.00    0.00    0.60
              99.10    0.00    0.48    0.00    0.00    0.42
              99.05    0.00    0.52    0.00    0.00    0.43
              98.98    0.00    0.52    0.00    0.00    0.50
              98.96    0.00    0.50    0.00    0.00    0.54
              98.88    0.00    0.51    0.00    0.00    0.61
              27.79    0.00    0.52    0.23    0.00   71.46
               0.45    0.00    0.24    0.01    0.00   99.30
    
    root@rockpro64:~# zgrep CONFIG_HZ /proc/config.gz 
    # CONFIG_HZ_PERIODIC is not set
    # CONFIG_HZ_100 is not set
    CONFIG_HZ_250=y
    # CONFIG_HZ_300 is not set
    # CONFIG_HZ_1000 is not set
    CONFIG_HZ=250
    
    
    
    
    
    
    RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11
    
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              76.64    0.00    0.60    0.17    0.00   22.59
              99.42    0.00    0.28    0.00    0.00    0.30
              99.48    0.00    0.26    0.00    0.00    0.25
              99.26    0.00    0.33    0.00    0.00    0.41
              99.34    0.00    0.33    0.00    0.00    0.33
              99.41    0.00    0.31    0.00    0.00    0.28
              99.28    0.00    0.34    0.00    0.00    0.38
              99.25    0.00    0.35    0.00    0.00    0.39
              99.41    0.00    0.31    0.00    0.00    0.27
              99.28    0.00    0.34    0.00    0.00    0.38
              99.28    0.00    0.30    0.00    0.00    0.42
              99.20    0.00    0.40    0.00    0.00    0.40
              99.38    0.00    0.31    0.00    0.00    0.31
              99.25    0.00    0.32    0.00    0.00    0.43
              99.27    0.00    0.35    0.00    0.00    0.38
              99.36    0.00    0.32    0.00    0.00    0.32
              99.38    0.00    0.29    0.00    0.00    0.34
              99.24    0.00    0.33    0.00    0.00    0.43
              99.26    0.00    0.32    0.00    0.00    0.42
              99.32    0.00    0.32    0.00    0.00    0.36
              99.45    0.00    0.29    0.00    0.00    0.26
              99.47    0.00    0.28    0.00    0.00    0.24
              99.42    0.00    0.33    0.00    0.00    0.25
              99.23    0.00    0.30    0.00    0.00    0.47
              99.31    0.00    0.34    0.00    0.00    0.35
              99.34    0.00    0.33    0.00    0.00    0.33
              99.24    0.00    0.33    0.00    0.00    0.43
              99.22    0.00    0.37    0.00    0.00    0.41
              99.25    0.00    0.35    0.00    0.00    0.40
              99.28    0.00    0.36    0.00    0.00    0.36
              99.16    0.00    0.42    0.00    0.00    0.43
              99.31    0.00    0.33    0.00    0.00    0.36
              99.31    0.00    0.33    0.00    0.00    0.36
              99.37    0.00    0.36    0.00    0.00    0.28
              99.36    0.00    0.31    0.00    0.00    0.33
              99.42    0.00    0.30    0.00    0.00    0.28
              99.22    0.00    0.37    0.00    0.00    0.41
              99.29    0.00    0.32    0.00    0.00    0.39
              99.24    0.00    0.36    0.00    0.00    0.40
              99.23    0.00    0.38    0.00    0.00    0.39
              99.33    0.00    0.33    0.00    0.00    0.34
              99.26    0.00    0.40    0.00    0.00    0.34
              99.34    0.00    0.34    0.00    0.00    0.33
              99.19    0.00    0.31    0.00    0.00    0.51
              99.33    0.00    0.32    0.00    0.00    0.35
              99.17    0.00    0.38    0.00    0.00    0.46
              99.17    0.00    0.37    0.00    0.00    0.47
              99.47    0.00    0.33    0.00    0.00    0.20
              99.22    0.00    0.31    0.00    0.00    0.47
              99.28    0.00    0.33    0.00    0.00    0.39
              99.25    0.00    0.36    0.00    0.00    0.39
              99.23    0.00    0.31    0.00    0.00    0.46
              99.25    0.00    0.33    0.00    0.00    0.42
              18.80    0.00    0.43    0.10    0.00   80.67
    
    root@rockpro64:~# gcc --version
    gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0
    Copyright (C) 2018 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    root@rockpro64:~# lsb_release -c
    Codename:	cosmic
    root@rockpro64:~# zgrep CONFIG_HZ /proc/config.gz 
    # CONFIG_HZ_PERIODIC is not set
    # CONFIG_HZ_100 is not set
    CONFIG_HZ_250=y
    # CONFIG_HZ_300 is not set
    # CONFIG_HZ_1000 is not set
    CONFIG_HZ=250

     

  14. Since the last round of Moronix madness didn't include a single RK3399 device I decided to give two rounds of silly kitchen-sink benchmarking a try using the 'reputable' Phoronix Test Suite:

     

    https://www.cnx-software.com/2019/02/13/odroid-n2-amlogic-s922x-sbc/#comment-560987

     

    For those thinking the N2 results would be better when running bare metal... I doubt it since of course I checked with sbc-bench first:

    • here's running sbc-bench on 'ODROID Bench' inside a container: http://ix.io/1BEM
    • and there's the results Dongjin (@tobetter) shared with me few days ago (look at the timestamp, Hardkernel tested already weeks ago so they were pretty clear about which benchmark results to publish and which not): http://ix.io/1BsF

    The ODROID-N1 numbers are representative for each and every RK3399 device out there running at 2.0/1.5GHz with CONFIG_HZ=250. Scores might improve once Rockchip provides new DRAM initialization BLOBs especially on those boards using LPDDR4.

  15. 4 hours ago, esbeeb said:

    I'm a noob to this whole zram thing, which I suspect is more trouble than it's worth

    Sure! That's the reason we switched to zram. For no other reason than generating troubles.

     

    4 hours ago, esbeeb said:

    Those zram device files are on my Sandisk Ultra MicroSD card

    Nope.

     

    4 hours ago, esbeeb said:

    My lightly-used SATA drive would be better for me, for running a traditional swap file from (due to its just sleeping all day otherwise)

    Absolutely not.

     

    4 hours ago, esbeeb said:

    I've set my "vm.swappiness" to 5 in /etc/sysctl.conf

    Bad idea.

     

    http://ix.io/1BEx (the stuff everyone should upload but nobody looks at then) shows that you never updated any Armbian packages so you're using an outdated configuration (zram-config package from Ubuntu and vm.swappiness set to a low value which is bad).

     

    You should backup your SD card, then upgrade your Armbian installation to get latest packages, set vm.swappiness to 100 and adjust /etc/default/armbian-zram-config for a nice overcommitment of 200%: ZRAM_PERCENTAGE=200, then reboot and try again.

     

    Those zram devices are not on your SD card (this would be absolutely stupid, ZRAM is about avoiding swap on slow storage like SD cards or HDDs). The next time you report back please show relevant output from armbianmonitor -u while you transferred a bit over FTP (why that? Why not Samba or anything else more sane?) so that swapping behavior can be observed.

  16. Funny place here...

     

    • All the RK3399 'benchmark' results collected so far were done with CONFIG_HZ=1000 (good for a responsive UI in Android and Linux, not so good for normal computing or server tasks) while everywhere around CONFIG_HZ=250 is the default. Is this affecting Blender or not? Anyone tested so far (latest ayufan images switched to CONFIG_HZ=250)? Anyone into Active Benchmarking instead of just firing up the next round of kitchen-sink benchmarks in fire-and-forget mode collecting more numbers without meaning?
    • The challenge with 'overclocking' the N2 is not trottling but stability/reliability as can be easily seen with the cpuminer tests that are sufficient for reliability testing (see N2 notes here). The DVFS OPP are defined in a closed firmware BLOB and the whole thing happens on the Cortex-M3 inside S922X.
    • N2 has no LPDDR4 but DDR4, memory performance depends not just on type of memory but on DRAM initialization (done with BLOBs on both RK3399 and S922X). TL Lim said Rockchip will provide a new BLOB to make use of faster LPDDR4 access on RockPro64 in 2018 but I don't know whether this has already happened or not
    • Memory benchmark scores depend on stuff like dmc or CONFIG_HZ since how would you explain better memory performance when switching from CONFIG_HZ=1000 to CONFIG_HZ=250 on RK3399 (previously known as difference between RK's 4.4 kernel and mainline though it's just different CONFIG_HZ defaults). Same with executing a memory benchmark on a little vs. big core
    • Memory bus width is different between S922X and RK3399 (32-bit vs. 64-bit) but whether this will result in faster execution depends on a lot of factors (application in question, DRAM initialization BLOB, kernel settings, kernel tunables, see dmc memory governor with RK3399, and so on)

     

    Added some updates to https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md#updates

  17. 28 minutes ago, tkaiser said:

    I understand risk beeing banned for providing wrong information!

     

    I didn't write this. Presenting this BS as part of a post is ensuring people with at least one brain cell left never coming back again.

     

    When I came across this initially I thought @memeka would've been brainwashed just to realize that this forum got brainwashed instead.

  18. 1 hour ago, lanefu said:

    wonderin where youve been

     

    Away. If censorship happens I leave. Ask @Tido since his actions in early October were the culprit (he won't understand anyway).

     

    Just tried out the 'new forum experience' and am really puzzled what this BS is all about. So this is now a 'support forum' and not a 'community forum' any more, great!

     

    Who signed support contracts with whom? Why is it now important to differentiate between questions for 'supported' boards and the others? What has happened to Armbian?

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines