Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Posts posted by tkaiser

  1. And two quick storage performance updates:

     

    1) This is the 8GB eMMC FriendlyELEC sells (write performance limited to 43 MB/s as it's mostly the case with low capacity eMMC, read performance exceeding 130 MB/s, nice random IO values -- compare with our overview):

                                                                  random    random
                  kB  reclen    write  rewrite    read    reread    read     write
              102400       4     8565     8793    24853    24808    19463     8523
              102400      16    25604    25986    66627    66701    56571    24459
              102400     512    42217    42326   125788   126508   125959    40394
              102400    1024    42762    43178   129692   129726   130452    42636
              102400   16384    43914    42877   132828   133254   133417    43012

     

    2) In the meantime I built also OMV images for NanoPC T4 and NanoPi M4 and did a quick LanTest benchmark with M4 and an externally connected Seagate Barracuda in an USB3 enclosure (not UAS capable -- but this doesn't matter with HDDs)

     

    Close to 100 MB/s sequential speed without any more optimizations is simply awesome:

    Bildschirmfoto%202018-09-14%20um%2022.47

    (debug output)

  2. 29 minutes ago, lanefu said:

    You want to edit image such as the official ones. I get it. No depencies on build. Pretty sweet actually

     

    Well, I'm not entirely sure how high the percentage of Armbian users is running Linux on the machine they deal with the downloaded Armbian image. I would believe that's less than 0.1% since the majority uses something called Windows or macOS.

     

    In fact those Linux users today already can simply loopmount the image and edit /boot/armbian_first_run.txt since /usr/lib/armbian/armbian-firstrun-config already exists and works.

     

    I thought about tweaking this mechanism to support more options like @botfap is currently doing but making this feature accessible to those +99% of Armbian users not able to mount an ext4 partition. That would require adding a 32MB FAT32 partition priot to the rootfs partition.

     

    On this partition labeled "Armbian" then the following will be:

    • armbian-firstrun-config.txt (here options can be set that are then processed by /usr/lib/armbian/armbian-firstrun-confi, ideally the defaults are also contained but commented so users get an idea how an otherwise unmodified Armbian install will work)
    • README.html (containing a brief overview how to access documentation, how to search the forum -- not just a stupid link to the forum but an explanation how to search the forum! -- and how to donate to the project)
    • a 'documentation' directory (containing an offline version of https://docs.armbian.com)

    The approach would be compatible with @botfap's work since when his tool is written in clean bash it can also run on macOS (I honestly don't care about Windows at all) and it just needs an additional mode where it generates armbian-firstrun-config.txt instead and his actual config tasks need to be merged into /usr/lib/armbian/armbian-firstrun-config

     

     

  3. 9 hours ago, TonyMac32 said:

    Can both of you keep notes on whether you get SD card corruption or failure to boot (with no obvious reason)?

     

    Not happened here with Rockchip so far (with EspressoBin I had issues but there I boot now from USB3 and ignore the SD card slot).

     

    Another interesting observation: My 2GB NanoPi M4 has higher memory bandwidth and lower memory latency compared to the 4GB version:

    BTW: I now also replaced the thermal pad on my 4GB NanoPi M4 with a copper shim + thermal compound and the results are impressive again: At the end of a sbc-bench run max. temperature is now at just 73.3°C (no throttling) compared to reaching 85°C throttling included with thermal pad.

     

    Those thermal pads suck.

     

    @hjc did you already look into lowering DVFS voltages? In the past we did this using a special Linpack version that is able to spot undervolted DVFS OPP before the board actually crashes.

  4. 2 hours ago, tkaiser said:

    71.7°C displayed but the average load next to it indicates that some other background activity happened in parallel (the 'cpuminer --benchmark' task on an otherwise idle RK3399 should not exceed 6.2 so the 6.6 of my test run indicate a problem -- I need to re-test again

     

    [x] Done. 70.6°C max reported now with cpuminer benchmark running but otherwise totally idle board lying flat on a surface.

     

    And then I repeated the test this time bringing the board in an upright position since as we can see from the thermal image above RockPro64 PCB is designed to also dissipate heat from SoC into the PCB's copper ground plane. So allowing some airflow around the whole PCB should help. And it does: 69.4°C now reported.

     

    The 1.2°C less do not tell anything relevant so better look at how temperatures changed while testing:

                  idle to 70°C   high to 50°C
    lying flat      420 sec        280 sec
    upright         --- sec        210 sec

    (with my limited time I was not able to test 'idle to 70°C' and this test is also flawed since the starting temperature is not fixed. That's why I always recommend to test with 2 consecutive sbc-bench runs and only look at the second run that starts with an overall warm board since cooling down from previous test run at always the same start temperature: sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 -- for details see here)

     

    Comparing with 'stock heatsink situation' (the grey thermal pad between SoC and heatsink) this is a nice improvement. With identical demanding task and external conditions (ambient temperature still at 24°C) temperatures went down from 85°C (with slight throttling occurring) to 71°C when executing the 5 minute benchmark run starting at 50°C. And by allowing some airflow around the whole PCB this gets even better and temperatures drop even a bit more.

     

    This is important for people wanting to avoid fans since by replacing the thermal pad with thermal compound and allowing for some airflow (no tiny enclosures!) they know they get maximum performance out of their board without throttling happening (the cpuminer benchmark is pretty demanding since making use of NEON optimizations 'normal' software doesn't use). As a comparison the lightweight sysbench 'cpu test' joke running for 20 minutes: sysbench --test=cpu --cpu-max-prime=200000000 run --num-threads=6

     
    
    root@rockpro64:/home/rock64# armbianmonitor -m
    Stop monitoring using [ctrl]-[c]
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    
    12:21:22: 1800/1416MHz  0.11   5%   0%   5%   0%   0%   0% 40.0°C  0/5
    12:21:28: 1800/1416MHz  0.58  25%   0%  25%   0%   0%   0% 44.4°C  0/5
    12:21:35: 1800/1416MHz  1.10  99%   1%  98%   0%   0%   0% 45.0°C  0/5
    12:21:41: 1800/1416MHz  1.49 100%   0%  99%   0%   0%   0% 45.0°C  0/5
    12:21:48: 1800/1416MHz  2.33 100%   0%  99%   0%   0%   0% 45.0°C  0/5
    12:21:55: 1800/1416MHz  2.62 100%   0%  99%   0%   0%   0% 45.6°C  0/5
    12:22:02: 1800/1416MHz  2.89 100%   0%  99%   0%   0%   0% 46.2°C  0/5
    12:22:08: 1800/1416MHz  3.45 100%   0%  99%   0%   0%   0% 46.9°C  0/5
    12:22:15: 1800/1416MHz  3.65 100%   0%  99%   0%   0%   0% 46.9°C  0/5
    12:22:22: 1800/1416MHz  3.84 100%   0%  99%   0%   0%   0% 46.9°C  0/5
    12:22:29: 1800/1416MHz  4.25 100%   0%  99%   0%   0%   0% 46.9°C  0/5
    12:22:35: 1800/1416MHz  4.39 100%   0%  99%   0%   0%   0% 46.2°C  0/5
    12:22:42: 1800/1416MHz  4.52 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:22:49: 1800/1416MHz  4.82 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:22:55: 1800/1416MHz  4.91 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:23:02: 1800/1416MHz  5.00 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:23:09: 1800/1416MHz  5.23 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:23:16: 1800/1416MHz  5.29 100%   0%  99%   0%   0%   0% 48.1°C  0/5
    12:23:23: 1800/1416MHz  5.47 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:23:29: 1800/1416MHz  5.52 100%   0%  99%   0%   0%   0% 47.5°C  0/5
    12:23:36: 1800/1416MHz  5.55 100%   0%  99%   0%   0%   0% 48.1°C  0/5
    12:23:43: 1800/1416MHz  5.70 100%   0%  99%   0%   0%   0% 48.8°C  0/5
    12:23:49: 1800/1416MHz  5.72 100%   0%  99%   0%   0%   0% 48.8°C  0/5
    12:23:56: 1800/1416MHz  5.74 100%   0%  99%   0%   0%   0% 48.1°C  0/5
    12:24:03: 1800/1416MHz  5.86 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:10: 1800/1416MHz  5.87 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:16: 1800/1416MHz  5.88 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:23: 1800/1416MHz  5.97 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:30: 1800/1416MHz  5.97 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:24:36: 1800/1416MHz  5.98 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:43: 1800/1416MHz  6.05 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:24:50: 1800/1416MHz  6.05 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    12:24:57: 1800/1416MHz  6.05 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:25:04: 1800/1416MHz  6.11 100%   0%  99%   0%   0%   0% 49.4°C  0/5
    12:25:10: 1800/1416MHz  6.10 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    12:25:17: 1800/1416MHz  6.09 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:25:24: 1800/1416MHz  6.15 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:25:31: 1800/1416MHz  6.14 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:25:37: 1800/1416MHz  6.13 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    12:25:44: 1800/1416MHz  6.18 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:25:51: 1800/1416MHz  6.17 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:25:58: 1800/1416MHz  6.22 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    12:26:05: 1800/1416MHz  6.20 100%   0%  99%   0%   0%   0% 50.0°C  0/5
    12:26:11: 1800/1416MHz  6.18 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:26:18: 1800/1416MHz  6.23 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:26:25: 1800/1416MHz  6.21 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:26:32: 1800/1416MHz  6.19 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:26:38: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 50.6°C  0/5
    12:26:45: 1800/1416MHz  6.22 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:26:52: 1800/1416MHz  6.20 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:26:58: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:27:05: 1800/1416MHz  6.22 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:27:12: 1800/1416MHz  6.20 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:27:19: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:27:26: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:27:32: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:27:39: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:27:46: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:27:53: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:27:59: 1800/1416MHz  6.28 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:28:06: 1800/1416MHz  6.26 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:28:13: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:28:20: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:28:27: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 51.1°C  0/5
    12:28:33: 1800/1416MHz  6.28 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:28:40: 1800/1416MHz  6.26 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:28:47: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:28:54: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:00: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:07: 1800/1416MHz  6.23 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:14: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:21: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:29:27: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:29:34: 1800/1416MHz  6.31 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:29:41: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:48: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:29:55: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 51.7°C  0/5
    12:30:01: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:30:08: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:30:15: 1800/1416MHz  6.28 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:30:22: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:30:28: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:30:35: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:30:42: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:30:49: 1800/1416MHz  6.28 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:30:56: 1800/1416MHz  6.26 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:31:02: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:31:09: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:31:16: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:31:23: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 52.2°C  0/5
    12:31:29: 1800/1416MHz  6.26 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:31:36: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:31:43: 1800/1416MHz  6.28 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:31:50: 1800/1416MHz  6.26 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:31:56: 1800/1416MHz  6.24 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:03: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:10: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:32:17: 1800/1416MHz  6.23 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:23: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:32:30: 1800/1416MHz  6.25 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:37: 1800/1416MHz  6.23 100%   0%  99%   0%   0%   0% 52.8°C  0/5
    12:32:44: 1800/1416MHz  6.43 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:51: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:32:57: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:33:04: 1800/1416MHz  6.53 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:33:11: 1800/1416MHz  6.49 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:33:17: 1800/1416MHz  6.49 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:33:24: 1800/1416MHz  6.45 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:33:31: 1800/1416MHz  6.41 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:33:38: 1800/1416MHz  6.42 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:33:45: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:33:51: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:33:58: 1800/1416MHz  6.38 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:34:05: 1800/1416MHz  6.43 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:34:11: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:34:18: 1800/1416MHz  6.41 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:34:25: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:34:32: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:34:39: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:34:46: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:34:52: 1800/1416MHz  6.31 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:34:59: 1800/1416MHz  6.41 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:06: 1800/1416MHz  6.45 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:13: 1800/1416MHz  6.46 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:20: 1800/1416MHz  6.42 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:26: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:35:33: 1800/1416MHz  6.40 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:40: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:35:47: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:35:54: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:00: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:07: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:14: 1800/1416MHz  6.40 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:21: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:36:27: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:36:34: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:41: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:36:48: 1800/1416MHz  6.44 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:36:54: 1800/1416MHz  6.40 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:37:01: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 55.0°C  0/5
    12:37:08: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:37:15: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:37:21: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:37:28: 1800/1416MHz  6.35 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:37:35: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:37:42: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:37:49: 1800/1416MHz  6.40 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:37:56: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:38:02: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:38:09: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 53.3°C  0/5
    12:38:16: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:38:22: 1800/1416MHz  6.36 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:38:29: 1800/1416MHz  6.33 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:38:36: 1800/1416MHz  6.30 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:38:42: 1800/1416MHz  6.52 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:38:49: 1800/1416MHz  6.51 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:38:56: 1800/1416MHz  6.47 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:39:02: 1800/1416MHz  6.43 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:39:09: 1800/1416MHz  6.44 100%   0%  99%   0%   0%   0% 55.0°C  0/5
    12:39:16: 1800/1416MHz  6.40 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:39:23: 1800/1416MHz  6.42 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:39:29: 1800/1416MHz  6.38 100%   0%  99%   0%   0%   0% 55.0°C  0/5
    12:39:36: 1800/1416MHz  6.35 100%   0%  99%   0%   0%   0% 55.0°C  0/5
    12:39:43: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    12:39:50: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:39:57: 1800/1416MHz  6.31 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:04: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:40:10: 1800/1416MHz  6.31 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:17: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:40:24: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:31: 1800/1416MHz  6.29 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:37: 1800/1416MHz  6.27 100%   0%  99%   0%   0%   0% 53.9°C  0/5
    12:40:44: 1800/1416MHz  6.37 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:51: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:40:57: 1800/1416MHz  6.32 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:41:04: 1800/1416MHz  6.34 100%   0%  99%   0%   0%   0% 54.4°C  0/5
    12:41:11: 1800/1416MHz  6.31 100%   0%  99%   0%   0%   0% 54.4°C  0/5^C

     

     

    Temperature stays at 55°C at an ambient temp of 24°C. Please note that once you cramp your board and heatsink in a tiny enclosure this will look entirely different.

  5. 20 minutes ago, Tido said:

    And TK can no longer blame you for being a bad manufacturer

     

    As if I would be interested in GPL violations. That's the last thing I care about. It just illustrations this total fail to get things right ('balance between NDA and open source' -- what a funny BS).

     

    The real problem with Realtek SoCs is this: https://www.cnx-software.com/2017/09/27/banana-pi-bpi-w2-is-a-features-packed-realtek-rtd1296-development-board/#comment-546422 (they have a VERY STRONG reason to keep everyone under NDA and to NOT publish their kernel sources and there will never be mainline support for these SoCs)

     

     

    A vendor who is not able to provide correct documentation (they are not able to even list the f*cking dimensions of their products correctly since they don't give a shit about accuracy :lol:) and constantly babbles about 'open source' instead of clearly communicating how things really are ('we can't share sources, we signed an NDA, you won't get access to what you need') and always chooses a new SoC for any new design... well, let's simply stop talking about this Dunning-Kruger show here.

  6. On 8/30/2018 at 8:15 PM, tkaiser said:

    Next test with thermal pad replaced by copper shim of same height and board still lying on the table:

    
    17:11:54: 1800/1416MHz  6.12 100%   0%  99%   0%   0%   0%  70.6°C
    17:12:06: 1800/1416MHz  6.10 100%   0%  99%   0%   0%   0%  71.1°C
    17:12:18: 1800/1416MHz  6.09 100%   0%  99%   0%   0%   0%  72.2°C
    17:12:30: 1800/1416MHz  6.13 100%   0%  99%   0%   0%   0%  73.9°C
    17:12:42: 1800/1416MHz  6.11 100%   0%  99%   0%   0%   0%  72.2°C

    No throttling and max temperature reported as 74°C.

     

    The above was with RockPro64 and a 1mm copper shim between RK3399 and heatsink. Since 2 NanoPi M4 arrived in the meantime I removed the heatsink and copper shim from RockPro64 to use the copper shim now with the NanoPi (with promising results). Now trying to get a really thin film of thermal compound on both RK3399 and the heatsink and then putting them both with nothng in between together:

     

    IMG_8022.JPG

     

    Full output from 'sbc-bench.sh -T 70 ; sbc-bench.sh -t 50' now https://pastebin.com/raw/hmRUMkGu and comparison to above:

    20:50:26: 1800/1416MHz  6.39 100%   0%  99%   0%   0%   0%  70.0°C
    20:50:38: 1800/1416MHz  6.44 100%   0%  99%   0%   0%   0%  68.9°C
    20:50:50: 1800/1416MHz  6.52 100%   0%  99%   0%   0%   0%  68.3°C
    20:51:03: 1800/1416MHz  6.62 100%   0%  99%   0%   0%   0%  70.0°C
    20:51:15: 1800/1416MHz  6.60 100%   0%  99%   0%   0%   0%  71.7°C

    As expected even better thermal values now: 71.7°C displayed but the average load next to it indicates that some other background activity happened in parallel (the 'cpuminer --benchmark' task on an otherwise idle RK3399 should not exceed 6.2 so the 6.6 of my test run indicate a problem -- I need to re-test again :( )

     

    But the good news is: if you get some thermal compound then you don't need a copper shim at all and can also avoid the thermal pad. But it's a good idea to use the thermal pad to cut some pieces and put them next to RK3399 to prevent shorts as can be seen above.

  7. 19 hours ago, botfap said:

    is it out of the question to have an extremely simple configuration framework? Maybe framework is more advanced than needed, probably just a script?

     

    Absolutely support this. But IMO discussion should be moved out of this thread in an own thread over at https://forum.armbian.com/forum/12-armbian-build-framework/

     

    @Igor can you please move last two posts to something like an 'Initial easy setup proposal' thread? I think a lot of users might benefit from a way to easily adjust the settings @botfap talked about prior to first boot.

  8. On 9/13/2018 at 11:44 AM, Lion Wang said:

    I've never told you anything because you're not nice,  i know you a orange pi fans , so I understand what you're doing

     

    LOL! Right, I almost forgot. You also don't give a shit about what's happening outside your company so any criticism is irrelevant and can be just the result of single persons being 'evil'. Ah, I love the 'Dunning-Kruger effect' so much :) 

     

    Hey @chwe: what to do with this technical discussion here? :P

     

    Edit: Updated archived version of these funny insights. Just in case BPi folks start to edit their posts: http://archive.fo/kL8tP

  9. 4 minutes ago, Nora Lee said:

    our company signed NDA with Realtek, we must follow Realtek's rule to release files under Realtek's approval

     

    This was already known. You violate the GPL not just by accident but knowingly and willingly. It can't be worse. You might feel save but you should keep in mind what happened to other GPL violators like D-Link.

  10. @Nora Lee and @Lion Wang thank you so much for confirming that nothing has changed within the last years.

     

    To summarize:

    • you don't understand the meaning of 'sources' in general
    • you don't understand the relevance of the GPL (forcing you or let's better say RealTek to immediately release the sources you build stuff from)
    • you don't understand that when you have to sign an NDA with a vendor you're becoming part of his GPL violations. Also it outlines your inability to understand the meaning of 'open source' in general
    • you don't understand the power and relevance of open source communities

    Adding to this you still alow the most careless person on this planet to do your 'technical documentation' (funky copy&paste jobs full of errors without thinking a single second) and it should be obvious why software support around your recent devices sucks that much.

     

    I bet you're already working on a Qualcomm or HiSilicon board just to ensure software support will be as terrible as we're all know it from your other boards (choosing each and every time a new SoC is such a brilliant move to ensure efforts are high and user expectations can never be met)

  11. 17 minutes ago, Nora Lee said:

    Bootloader and kernel under developing, draft version will be provided with developers, improving version will be released in public

     

    OMG, you Banana folks will never get it. You and RealTek are not just plain GPL violators but if your above statement is true (which I doubt) you act also as stupid as in the past preventing talented community members helping you. Ask @frank-w, ask @Tido (maybe he'll explain to you again the 'release early, release often' benefits)

     

    My guess is you simply don't get sources from RealTek...

  12. 34 minutes ago, hjc said:

    using a MacBook charger on M4 is not even better than those old USB-A phone chargers with 5V 2A output without any quick charging protocol?

     

    The problem is that 'true' USB-C chargers limit current to 500mA or 900mA if the other end of the USB-C cable is not able to negotiate the demand for higher currents. And those 5V SBC with USB-C right now (Vim2 and now also NanoPi M4) don't do this. They act in 'dumb' mode and require the PSU to provide 'current without asking' which standard compliants USB-C chargers will refuse. So you need a dumb or tolerant charger too.

     

    I've measured booting current with my dumb PSU and this was reported as above 5.6W which would translate to +1100mA which is well above what a standards compliant USB-C charger is allowed to provide to a dumb device.

     

    34 minutes ago, hjc said:

    Anyway this supports your view that the official 5V/4A charger should be purchased as well.

     

    Yes, I hope this one does well. No chance to test yet since missing the needed adapter (also available in FriendlyELEC's online shop and also a recommendation for those affected then):

     

    IMG_8025.JPG

  13. And now a quick look at NanoPi M4's massive heatsink. Since I have 2 boards with one board I used the supplied blue thermal pad between RK3399 and heatsink and on the other board instead of thermal pad a 20x20mm copper shim of 1 mm height with a thin film of thermal compound on both sides.

     

    Test methodology is sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 (reasons why). Full results: Thermal pad and copper shim

     

    Yes, it's a bit hard to interpret this stuff but detailed interpretation is necessary having the design of the heatsink in mind:

    • the thing is massive (huge own thermal mass)
    • the heatsink has fins where air can be directed through (one large and silent fan can easily cool down a whole bunch of M4 with controlled airflow)
    • the heat conductivity of the material between heatsink and SoC plays also an important role

    I'm in the process of doing a lot more tests (to generate insights, not fancy graphs and numbers) but for now only the following data revealed (that needs confirmation, I'm not entirely sure if testing with two boards is not a flaw)

     

    Let's look at temperatures at the end of both sbc-test thermal tests (the first pre-heats to 70°C, the second one waits until SoC temperature is as low as 50°C):

                   start 70°C     start 50°C
    thermal pad      85.0°C         85.0°C
    copper shim      79.4°C         74.4°C

    Copper shim with thermal compound 'wins' but with such a massive heatsink better heat conductivity also has its downsides. So let's look at how fast switching between temperatures works:

                  idle to 70°C   high to 50°C
    thermal pad      75 sec        330 sec
    copper shim     600 sec        750 sec

    Results in the first row look reasonable to me (the better the SoC's heat can be dissipated into the massive heatsink the longer it takes until SoC/board temperature rises). The 2nd row (cooling down) IMO needs more investigation since I would've thought that the cooling time would be somewhat similar. But for this I most probably need precise thermal measurements to get a clue about the heatsink temperature itself. At least now when testing with the copper shim efficiently dissipating the SoCs heat into the aluminium block the heatsink gets too hot to handle when SoC temperature is reported as being higher than ~65°C for some time.

     

    All of the above was talking about true passive mode. But of course the heatsink is sufficient to be used with active cooling too. Just blow a little bit of air laterally through the heatsink fins and the board can do whatever power hungry task you want and stays cool forever.

     

    Quick experiment now at a customer: I put the NanoPi M4 directly behind the air outlet of an annoying noisy Xeon server's PSU so that the 'waste heat' coming out of the server goes through the heatsink fins. Running cpuminer on the M4 in the background scoring 8.8kH/s constantly and temperature below 43°C (at an ambient temp of 18°C in the server room, but the 'waste heat' coming out of the PSU is definitely a bit 'warmer'): https://pastebin.com/raw/s1zvyfU6

     

    TL;DR: the massive heatsink is great even in total passive mode when only short load bursts happen (then heat gets efficiently dissipated into the aluminium block, even better with a copper shim instead of thermal pad). For high loads over longer periods the heatsink is still fine without additional ventilation as long as you're comfortable with electronics devices being operated at higher temperatures. To improve heat dissipation simply blowing some air through the heatsink fins is sufficient.

     

    I think my further testings will focus on the difference between FriendlyELEC's approach (huge thermal mass and heatsink fins more or less only efficient when combined with some airflow) and RockPro64's implementing a different strategy and now even more efficient since there RK3399 and heatsink can also be connected directly with just some thermal compound in between:

     

    IMG_8022.JPG

  14. On 9/3/2018 at 4:38 PM, mindee said:

    SSD performance are measured by command "iozone -e -I -a -s 1G -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2", SD card and eMMC are using 100M instead of 1G size.

     

    I'm now also testing IO performance on NanoPi M4 to get an idea how much influence the integrated VIA VL817 USB3 hub has. The following test command is used since I test with an el cheapo Samsung EVO 840 (known to exceed 500 MB/s on a SATA port but low capacity and implementing TurboWrite)

    taskset -c 4 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    sleep 300
    taskset -c 4 iozone -e -I -a -s 2000M -r 16384k -i 0 -i 1 -i 2

    Why do I test first with 100 MB, then wait 5 minutes and test again with 2 GB?

    • Tests with 100 MB to keep results comparable with my previous collection
    • An additional test with 2 GB since we found that with fast USB3 implementations and fast SSDs the maximum throughput isn't reported when testing with low test sizes. 1GB or better 2GB seem like a reasonable additional test to look for real maximum bandwidth possible
    • Why waiting for 5 minutes (sleep 300) in between? Since my 128GB EVO840 implements TurboWrite and therefore is only capable to write data at maximum speed until the TurboWrite buffer is full. So if I would've tested all block sizes with 1GB test data size the EVO itself would've turned into a bottleneck after approx. 2.5GB data written
    • Why 'taskset -c 4' (executing the test on a big core)? Since we're looking for maximum performance here

    Raw results as follows

                                                                  random    random
                  kB  reclen    write  rewrite    read    reread    read     write
              102400       4    25559    28658    21964    22012    21957    28183
              102400      16    84846    94435    80322    80926    81083    92975
              102400     512   325556   326434   289616   292997   294076   322974
              102400    1024   347800   362005   324009   327371   329460   352963
              102400   16384   381091   386458   370522   373441   373337   378399
             2048000   16384   401465   402916   375361   375457   375509   398665

    In other words: Even with an USB3 hub in between storage performance is excellent as long as only one disk is connected (with more than one disk and accesses in parallel performance will of course drop since then bus contention issues might occur and bandwidth has to be shared). But with HDDs this is no issue at all since they're too slow anyway.

     

    Storage performance summary: I've had some fear that the internal USB3 hub will trash storage performance but that's not true (at least when only one disk is connected). As a reference numbers generated with same SSD, same settings and same test methodology on discontinued ODROID-N1 (as an example for RK3399 USB3 without hub and also with same SSD connected to a cheap PCIe SATA controller):

                          Random IO in IOPS     Sequential IO in MB/sec
                            4K read/write           1M read/write
    ODROID-N1                 5994/6308               330 / 340
    NanoPi M4                 5489/7045               330 / 355
    ASM1061 powersave         6010/7900               320 / 325 
    ASM1061 performance       9820/16230              330 / 330

    The ASM1061 numbers are especially dedicated to all those SBC users believing into 'native SATA'. Sequential storage performance with a good UAS capable USB3-to-SATA bridge is higher compared to cheap PCIe SATA controllers. 'Native' SATA does not exist with RK3399 anyway and for really high SATA storage performance more expensive SATA controllers making use of more than 1 PCIe lane are necessary. But with just an ASM1061 the only two real benefits of PCIe attached SATA over USB3 attached SATA are

    • higher random IO performance
    • less IRQs to process which results in less CPU utilization (see ODROID-N1 link above)

    But to attach one or two USB3 HDDs and share them at maximum speed (~100 MB/s through network) the NanoPi M4 is perfectly fine.

     

    Edit: Debug output here. We can see the usual 'ERROR Transfer event for disabled endpoint or incorrect stream ring' XHCI error when connecting an USB3 disk enclosure the first time (known problem but doesn't cause any harm) and amount of DRAM is reported differently since I swapped the SD card between my two NanoPi M4

  15. On 9/2/2018 at 9:34 AM, hjc said:

    NanoPi M4 is my first board powered by USB-C

     

    Yesterday 2 sets of NanoPi M4 arrived (one 2GB and 4GB) which will make it convenient to test for stuff like heat dissipation in less time (I use one time the supplied thermal pad with the large heatsink, on the 2nd board I replaced the thermal pad with a 20x20mm copper shim of 1mm height I took away from my RockPro64).

     

    But now talking just about USB-C: NanoPi M4 while using an USB-C connector to be powered is obviously not USB PD compliant but simply uses the USB-C connector to be combined with a 'dumb' PSU that provides the necessary amount of current without any negotiation. FriendlyELEC shipped a new 5V/4A PSU with USB-A receptacle combined with a very short USB-C cable. Since the PSU is not EU style and I miss the necessary adapter I currently use my standard 'dumb'  5V/2A USB PSU which works fine for the tests I currently do.

     

    Not being compliant to USB PD specs (or USB-C powering specifications) means two things: Pro: no expensive USB-C charger needed (check the funny discussion in Khadas forum and there the link to tested USB-C chargers and their prices). A dumb 5V PSU that can deliver the needed amount of current at a stable voltage will be sufficient

     

    Cons:

     

    Edit: tested with my MacBook Pro USB-C charger not exceeding 500mA with 'dumb' consumers on the other end of the USB-C cable: endless boot/crash cycle. So be prepared to run into troubles combining NanoPi M4 with a real USB-C charger compliant to specs. This didn't work with the Vim2 and it also does not work with NanoPi M4. @hjc: seems you can consider yourself lucky that your USB-C charger is outputting more than 500/900 mA when feeding 'dumb' consumers.

  16. 1 hour ago, codnoscope said:

    I don't have any UEFI specific use case, just want to tinker

     

    With something that's broken by design? Adding tons of complexity for no real reason and allowing to backdoor your system at a level the OS can never detect? Ever done a simple web search for 'uefi security vulnerabilities issue' or something like that?

  17. 1 hour ago, Igor said:
    Quote

     or Armbian officially


    :wacko::angry: 

     

    Well, as expected.

     

    1 hour ago, Igor said:

    That actually works, but we obviously lack a properly placed how-to

    Talking about this https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstrun-config?

     

    If so this is as useless for average users as what I do all the time: let customize.sh throw an appropriate NM profile into /etc/NetworkManager/system-connections/ at image creation time. Average users would need a FAT partition so they can access it from Windows or macOS. But instead we should emphasize that on our officially supported boards w/o Ethernet a remote console sits on the MicroUSB port waiting for the user to login.

  18. 1 hour ago, hjc said:

    IMO The biggest and only problem so far for all RK3399 boards is pricing

     

    Couldn't agree more and still ask myself what I did the first time I heard of RK3399 boards: 'what's the use case for an ARM board that costs as much as a real Mini PC?' If the special capabilities of such devices (dual camera input, image processing, attaching a bunch of displays -- no idea what works with Linux and what only with Android) aren't used what's the point of spending huge amounts of money on these things?

     

    But maybe it's only me. At least I don't want to spend ~40 bucks just on a PSU (USB-C PD compliant) for such a device or +20 bucks to get appropriate heat dissipation (applies to Khadas Edge/Edge-V -- ~60 bucks for 'basic' accessories but users seem happy)

     

    1 hour ago, gounthar said:

    So I chose a perk which contained their USB-C charger to avoid any problem.

     

    Wow, 100 bucks (with a 20% Indiegogo discount) for 128GB storage and the PSU.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines