tkaiser

Members
  • Content count

    5116
  • Joined

  • Last visited

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

13261 profile views
  1. tkaiser

    NanoPC T4

    So in the end we discussed a lot and then @Igor decided to use another kernel branch: https://github.com/armbian/build/blob/6d82a8974872ee261006d2cdf6726b7d13df5032/config/sources/rk3399.conf#L34
  2. tkaiser

    Samba work poorly or not at all

    Your board crashed, log2ram was not able to write /var/log contents back to disk and an 'mkdir -p /var/log/samba ; reboot' as root will most probably fix it.
  3. tkaiser

    Benchmarking CPUs

    To create awareness that the amount of data to test with is important and to outline that initialization overhead is something to consider. The whole approach is not to generate graphs and numbers to compare without using the brain but to generate insights instead.
  4. tkaiser

    Cubietruck & Armbian SSH login message

    A better question is why this motd stuff needs to be broken? If the goal of Igor's motd is to display information then simply reading a random file /etc/armbian-release not containing information but just a bogus number is obviously not the correct way. A more sane way might be to parse 'dpkg -l | grep "^armbian"' output and report the highest package number. But why such a waste of time at every login? I don't like this motd stuff delaying logins anyway, I also don't like creating confusion and misinformation but weighing both I gave up dealing with this motd stuff after trying to fix most severe performance issues some time ago.
  5. tkaiser

    NanoPC T4

    Did you prefix the iozone call with 'taskset -c 4-5 '?
  6. tkaiser

    Annoying fan noise on XU4

    Buying a fast board to operate it slow is an option? Really? I would cap max frequency of the big cores from 2.0 GHz to 1.8 GHz or maybe 1.6GHz (/etc/default/cpufrequtils) and then check again. The upper DVFS operating points have to use a much higher voltage to get CPU cores working stable so the amount of heat the SoC dissipates at the top clockspeeds is much higher than slightly below. I would prefer a 5% or 10% performance drop instead of running slow all the time. And yeah, the fansink is a joke since not sufficient to provide appropriate cooling. With demanding workloads throttling will always occur (you can't run anything really heavy at 2.0 GHz with the fansink) and the sound is annoying. BTW: To diagnose and optimize behaviour running 'armbianmonitor -m' in a shell is always a good idea. In case the CPU cores run at high clockspeeds with ondemand even when idle this might be another occurence of 'sampling_rate' being inapppropriate with recent kernels.
  7. tkaiser

    RockPro64

    Don't think so and irqbalanced is broken on ARM anyway
  8. tkaiser

    Trying to compile Pine H64

    That's only Hi-Speed but not SuperSpeed: Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 006 Device 004: ID 174c:1153 ASMedia Technology Inc. ASM2115 SATA 6Gb/s bridge ... /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M But nice to see that we get +41MB/s with UAS Mass Storage protocol and "USB2" (correctly called Hi-Speed) Edit: It's not even UAS that gets negotiated.
  9. So you can neither power through GPIO any more nor use their own 'special' PSU since this thing is a 5.0V PSU and not a 5.25V as required?! What do these guys think? The problem is known since day one! Skip the entire review and just look at 2:19: https://www.youtube.com/watch?v=y4EIhh0VT5g#t=2m19s Edit: @TonyMac32 updated his results and so still powering through GPIO header is the way to go with Tinkerboard:
  10. tkaiser

    Trying to compile Pine H64

    Next week. Now on a business trip. Thank you for all your support!
  11. tkaiser

    Trying to compile Pine H64

    I benchmarked the PineH64 now at 1800 MHz: https://github.com/ThomasKaiser/sbc-bench/commit/2f4dfe6a21db48bc130fc3801b78caf4412bb048 Are you also running Allwinner's BSP on H6 boards? Would be pretty interesting to get tinymembench results with BSP DRAM initialization and kernel (see end of the thread)
  12. tkaiser

    Trying to compile Pine H64

    Doesn't do the trick -- still below 80MB/s: root@pineh64:/mnt/sda# /usr/local/src/devmemX/devmem2 0x03001510 w 0x03000002 root@pineh64:/mnt/sda# iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1 | grep 102400 File size set to 1024000 kB 1024000 16384 77356 77853 348247 349195
  13. tkaiser

    Trying to compile Pine H64

    Yes, RK3328, RK3399, Exynos 5244. Error messages on RK once the enclosures appear on the bus: [ 1503.960555] xhci-hcd xhci-hcd.2.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 1503.960574] xhci-hcd xhci-hcd.2.auto: @00000000b684e310 00000000 00000000 04000000 03038001 I wonder whether the tinymembench numbers are ok (especially memcpy) and whether we can compare with Allwinner BSP?
  14. tkaiser

    Trying to compile Pine H64

    No FEL setup here currently. Is there an dev2mem alternative? Anyway: Just added PineH64 with 1800 MHz to the list: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md Quick look at USB3: When attaching my EVO840 SSD in UAS capable disk enclosures (JMS567 and then ASM1153) I get these messages. [ 1890.116983] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1 ep 6 [ 1890.116987] xhci-hcd xhci-hcd.0.auto: @00000000b8048580 00000000 00000000 1b000000 01078001 ... [ 2444.903488] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for unknown stream ring slot 1 ep 2 [ 2444.903493] xhci-hcd xhci-hcd.0.auto: @00000000b8048b20 00000000 00000000 1b000000 01038000 UAS storage performance as follows (forget about the ASM1153 numbers, this enclosure can not be powered externally, doesn't get enough juice my PineH64's USB3 port -- I have an early developer sample 'Model A' -- and therefore chooses a strategy to deal with underpowering --> lowering performance) EVO 840 / JMS567 random random kB reclen write rewrite read reread read write 102400 4 6090 6479 6300 6358 6403 6508 102400 16 24386 24449 24493 24570 24570 24445 102400 512 72744 72826 253654 261201 260663 72693 102400 1024 73473 73695 302101 314144 313409 74325 102400 16384 73443 77008 336140 350131 348980 76653 102400 16384 73768 77008 336151 350292 EVO 840 / ASM1153 (under)powered by PineH64 random random kB reclen write rewrite read reread read write 102400 4 6464 6907 6427 6424 6493 6828 102400 16 24434 24532 24956 25071 25039 24482 102400 512 70552 70668 87827 88720 88691 70667 102400 1024 70528 70713 92226 93154 93183 70684 102400 16384 69263 72237 96030 96996 97009 72169 102400 16384 69044 71879 96031 97134 Read performance isn't bad but write is too low. I remember @Xalius reported the same when playing with H6 already months ago. I also tested with the RTL8153 dongle that is known to saturate link speed (940 Mbits/sec). Too early since only ~200 Mbits/sec in both directions. Onboard GbE looks promising (though there's a few Mbits/sec missing in TX direction): bash-3.2# iperf3 -c 192.168.83.65 Connecting to host 192.168.83.65, port 5201 [ 4] local 192.168.83.64 port 60382 connected to 192.168.83.65 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 113 MBytes 948 Mbits/sec [ 4] 1.00-2.00 sec 112 MBytes 940 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 940 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 940 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 940 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 940 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 940 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 940 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 940 Mbits/sec [ 4] 9.00-10.00 sec 112 MBytes 940 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver iperf Done. bash-3.2# iperf3 -R -c 192.168.83.65 Connecting to host 192.168.83.65, port 5201 Reverse mode, remote host 192.168.83.65 is sending [ 4] local 192.168.83.64 port 60379 connected to 192.168.83.65 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 108 MBytes 902 Mbits/sec [ 4] 1.00-2.00 sec 108 MBytes 905 Mbits/sec [ 4] 2.00-3.00 sec 108 MBytes 905 Mbits/sec [ 4] 3.00-4.00 sec 108 MBytes 905 Mbits/sec [ 4] 4.00-5.00 sec 108 MBytes 905 Mbits/sec [ 4] 5.00-6.00 sec 108 MBytes 905 Mbits/sec [ 4] 6.00-7.00 sec 108 MBytes 905 Mbits/sec [ 4] 7.00-8.00 sec 108 MBytes 905 Mbits/sec [ 4] 8.00-9.00 sec 108 MBytes 905 Mbits/sec [ 4] 9.00-10.00 sec 108 MBytes 905 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.06 GBytes 906 Mbits/sec 1 sender [ 4] 0.00-10.00 sec 1.05 GBytes 905 Mbits/sec receiver iperf Done. Full debug output (including dmesg output for USB events): http://ix.io/1jEy
  15. tkaiser

    Trying to compile Pine H64

    Already patched and benchmarking. My board seems to be fine with 1800 MHz @ 1080mV