• Content count

  • Joined

  • Last visited

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

11847 profile views
  1. tkaiser

    NanoPC T4

    This is something hopefully suitable to become a 'Board Bring up' thread. The NanoPC T4 is probably the smallest RK3399 board around featuring full set of interfaces (Rock960 is smaller but there you can't use GbE without a proprietary expander) Pros: Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1 Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card) Cons: A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline). Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth). Internal 16 GB eMMC performance: eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is a sign that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there) Quick USB3 performance test via the USB-3A port: Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 /mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399. This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour: 13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think? Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy. Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with consumption and performance), different interfaces and different power circuitry (and different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).
  2. tkaiser

    BSP scripts RFC

    My 2 cents on this at the bottom of the list: Can't really test/review at the moment since running out of spare time. My only other 'Armbian contribution' this week will be a little bit NanoPC T4 testing (relying on @hjc's work).
  3. tkaiser


    You should keep in mind that your SSD wants (and gets on Intel) PCIe Gen3 ('LnkCap: Port #0, Speed 8GT/s, Width x4') and that RK's 4.4 kernel allows for PCIe power management (defaulting to 'powersave'). I would assume retesting with adjusted /sys/module/pcie_aspm/parameters/policy sysfs node won't change results with larger blocksizes and that's most probably since your SSD wants Gen3 link speed to perform great (seen this several times in reviews that even if the theoretical max bandwidth of a Gen2 x4 link would be more than sufficient the same SSD performs faster on a Gen3 x2 link which would allow for the same transfer rates)
  4. tkaiser


    In the meantime I ordered an USB-C drive enclosure based on VIA VL716. A quick check with lsusb shows 'Bus 008 Device 002: ID 2109:0715 VIA Labs, Inc.' (that's the same product ID as VIA's VL715 which is basically the same chip as the VL716 but the latter contains the USB-C stuff). My first test was disappointing since performance looked like USB2 and a quick 'lsusb -t' confirmed. The enclosure only established a Hi-Speed but no SuperSpeed connection. After replugging the cable it worked one time but then I got connection issues (that looked like UAS software troubles as usual in the logs). Now after a reboot it looks like this: random random kB reclen write rewrite read reread read write 102400 4 15833 21863 24630 24740 15728 17119 102400 16 41332 57594 63793 63974 53032 57263 102400 512 236008 246826 232867 238458 231778 231332 102400 1024 282755 296478 280089 282768 279200 295004 102400 16384 377360 377555 388708 396527 395120 383106 Well, numbers look ok but I've to admit that USB storage kinda sucks. 'Armbianmonitor -u' output:
  5. tkaiser


    You need to adjust DT on your NanoPC since the device claims to be only capable of PCIe Gen1. Please see also @FrankM: Would be interesting to test on your RockPro64 with link speed set to 1 and see whether now a x4 link will be established:
  6. tkaiser


    Yes, tkaiser has tested this already. On another RK3399 device: And here you find a general storage performance overview also covering RK3399 devices: ODROID-N1 in my tests was also running RK's 4.4 kernel, they use the same ASM1061 controller Pine folks sell as Add-On card, the only other performance relevant parameters are CPU clockspeeds (these are simple tunables in the device tree to let the CPU cores clock slightly higher) DRAM initialization/parameters (we should get a slight speed improve on RockPro64 in the future once LPDDR4 memory uses optimized settings) Settings (e.g. PCIe power management active or not -- see the ODROID N1 thread above) So everything is already known. :-)
  7. tkaiser


    I've seen x4 so far only with mainline (4.16 back then): (this is on Theobroma's Q7-RK3399 -- maybe different trace routing is also important?)
  8. Like all of those list it's not worth to visit them since they're full of mistakes. That's only for people who are impressed by vast amounts of data and don't give a sh*t about information (data != information). 3 examples after looking for ONE MINUTE into this BS collection: Banana Pi M2 Berry is listed with 4 USB ports while this board in reality just uses one USB host port to provide 4 USB receptacles (shared bandwidth due to internal USB hub). Banana Pi M2 Ultra is also listed with 4 USB ports which is BS since this board has 2 USB receptacles (+ 1 x Micro USB OTG port) and at least exposes all of the USB host ports CubieBoard6/7 is listed as one entry which is OK from a hardware point of view (since the pin compatible S500/S700 SoCs are the only change between both board variants). But under 'OSes' for both boards 'Linux, Android' is listed which is simply BS since Cubieboard 7 with it's Actions Semi S700 SoC is simply an Android toy only. No Linux image has been made available, there's only one smelly 3.10 kernel that receives no updates since a long time any more and the vendor is known for providing horrible software support these days anyway. After spotting that much errors within a minute I stopped and closed the browser tab. It's just a waste of time to look through a huge collection of data providing zero (correct) information. Also the most important factor if you also want to USE a SBC and not just buy one is missing: quality of software support. Everybody should know that 'software support' makes the difference between a SBC and a paperweight or door stop. This collection of (partially wrong) data does not differentiate at all so it's completely useless.
  9. tkaiser

    CPU governor stays at ondemand

    With Xenial it was this way: -- so I would assume with Bionic they do it now differently and we have to mask another service?
  10. tkaiser

    Image backup how to

    And do on the running system this prior to compressing: dd if=/dev/zero of=/lala bs=1M || rm /lala Usually reduces the size of the compressed image by magnitudes since zeroes compress better than random garbage (it's a block device that gets compressed so this does not happen at the filesystem layer --> everything that has been deleted is still there on the block device) As a side note: there are two search functions here, the search bar using the crappy/useless internal forum search and 'Google site search'. This topic has been discussed in detail many many times.
  11. tkaiser


    Nope, every Northbridge cooler with a mounting hole distance of 60 mm will work. Latest ayufan release from few hours ago activated USB so let's do a quick USB3 storage benchmark with an EVO840 in a JMS567 enclosure. Testing with our usual iozone benchmark: random random kB reclen write rewrite read reread read write 102400 4 19833 26941 35089 35464 24545 26763 102400 16 66374 85914 107740 108213 79784 86035 102400 512 308034 318723 298717 301950 293118 316910 102400 1024 335762 349205 335279 338808 330313 346358 102400 16384 379379 382513 378721 383947 383529 384295 1024000 16384 397369 402562 384391 384846 Up to 400 MB/s as expected. Current ayufan images are yet not optimized for performance. They're missing increase in CPU clockspeeds (1.4/1.8 GHz instead of 1.5/2.0 GHz) and also do not use latest DRAM initialization (RockPro64 is the first RK3399 device using LPDDR4 so with appropriate DRAM initialization everything memory dependent -- e.g. I/O DMA -- will be faster afterwards) I also did a quick iperf3 test in the meantime: +940 MBits/sec in both directions after ayufan adjusted TX/RX delay values:
  12. tkaiser

    Odroid C2 - update to v5.44 / v5.45 not working?

    Well, every other week the same question is asked here so the mechanism to display a random version number contained in /etc/armbian-release that is part of one specific package that doesn't get updated each time Armbian version number is increased is obviously misleading.
  13. tkaiser

    Librecomputer Tritium H3

    I give up. A development branch has been created out of nowhere, master has been abandoned and all active work happened in development with nothing 'stable' merged into master any more. At the same time stuff that would need testing still landed in master as part of PRs (so splitting development from master was absolutely useless at all). Zador wasted his time to rebase development few days ago and now in huge commits changes that have been made in development are 'ported' to master? At the same time PRs that destroy the whole build system (and my settings) get merged for no reason... Smells just like a huge waste of time again and again...
  14. tkaiser

    Odroid C2 - update to v5.44 / v5.45 not working?

    Your installation is on 5.45 What Armbian displays with Igor's motd stuff is broken. That's all. The motd routine displays a meaningless version number based on one package's version that does not get updated every time Armbian's version number increases. It's only there to confuse people and generate unnecessary support efforts. Don't expect this to be fixed :-)
  15. tkaiser


    (placeholder for a Board Bring Up thread -- now just collecting random nonsense) Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values: below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.