hojnikb Posted January 26, 2017 Posted January 26, 2017 Tried image, works very smoothly for a test image. I did notice, that frequency seems to stay at 1.3Ghz, but quickly drops down to 1.0Ghz with a bit of load (like scrolling). Is this normal behavior ? Shouldn't cpu in idle sit at lowest possible frequency and only ramp when needed ? As for stability testing; cpuburn-a53 is for stressing, what about testing for actual stability ? What app is the best for that ? 0 Quote
jernej Posted January 26, 2017 Posted January 26, 2017 As for stability testing; cpuburn-a53 is for stressing, what about testing for actual stability ? What app is the best for that ? You want stability under stress, so... 0 Quote
hojnikb Posted January 27, 2017 Posted January 27, 2017 You want stability under stress, so... i don't think cpuburn checks for errors, so it's useless on it's own beyond heating the board. Would a custom script of x264 or something like that do the job ? 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 To check the stability of the board have a look at this post: #91 It has all the links to the info you need to check the stability of the board. 1 Quote
tkaiser Posted January 27, 2017 Posted January 27, 2017 i don't think cpuburn checks for errors, so it's useless on it's own beyond heating the board. If you are not willing to help why don't you simply stop here instead of blowing up this thread with more and more pages full of useless conversation? As already said: it requires some time and will to contribute, 'fire and forget' doesn't work and always questioning any advice you get (from people that went already through this) is maybe also not the smartest move? While cpuburn unlike other tools does not 'check' for errors it triggers them reliably since as soon as throttling jumps in cpufreq will be adjusted and this automatically tests through the different DVFS operating points (and if undervoltage occurs you get a nice kernel panic and stuff like that). But as ErwinH already said: Without reading carefully through the links provided it's just a waste of time... 0 Quote
hojnikb Posted January 27, 2017 Posted January 27, 2017 Given how information is scattered all over the place, it's no wonder noobs don't find appropriate information and thus ask on the forums. After all, thats what forums are for. 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 Your title says your an advanced member, and you are running a beta (should it even be named beta) image for a board that has a runnable image for 2 days. That would mean to me you've got the knowledge to find the information you need. Running stability tests got a lot of pitfalls and you need to be able to identify those to add any value to the results. 0 Quote
zador.blood.stained Posted January 27, 2017 Posted January 27, 2017 Hm. Something is wrong with the OPP table anyway analyzing CPU 3: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.24 ms. hardware limits: 792 MHz - 1.37 GHz available frequency steps: 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 792 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 792 MHz (asserted by call to hardware). cpufreq stats: 792 MHz:77.05%, 816 MHz:1.07%, 864 MHz:0.00%, 912 MHz:0.21%, 936 MHz:0.00%, 960 MHz:0.21%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.08 GHz:0.00%, 1.10 GHz:0.00%, 1.15 GHz:0.23%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:20.85%, 1.34 GHz:0.00%, 1.37 GHz:0.38% (34) Looks like OPPs below 792MHz were not added [ 1.853650] core: _opp_supported_by_regulators: OPP minuV: 980000 maxuV: 980000, not supported by regulator [ 1.853658] cpu cpu0: _opp_add: OPP not supported by regulators (768000000) [ 1.853722] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator [ 1.853727] cpu cpu0: _opp_add: OPP not supported by regulators (720000000) [ 1.853775] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator [ 1.853780] cpu cpu0: _opp_add: OPP not supported by regulators (672000000) [ 1.853844] core: _opp_supported_by_regulators: OPP minuV: 970000 maxuV: 970000, not supported by regulator [ 1.853848] cpu cpu0: _opp_add: OPP not supported by regulators (648000000) [ 1.853895] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator [ 1.853899] cpu cpu0: _opp_add: OPP not supported by regulators (528000000) [ 1.853947] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator [ 1.853951] cpu cpu0: _opp_add: OPP not supported by regulators (480000000) [ 1.854017] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator [ 1.854022] cpu cpu0: _opp_add: OPP not supported by regulators (240000000) [ 1.854069] core: _opp_supported_by_regulators: OPP minuV: 940000 maxuV: 940000, not supported by regulator [ 1.854074] cpu cpu0: _opp_add: OPP not supported by regulators (120000000) Edit: regulator-min-microvolt = <1000000>; so the regulator can't go lower than 1V and all OPPs that reference <1V are discarded. 0 Quote
tkaiser Posted January 27, 2017 Posted January 27, 2017 regulator-min-microvolt = <1000000>; So we need 'regulator-min-microvolt = <940000>;' instead? @ErwinH: Did you test the board with these lower OPP too? Eg. by adjusting cpufreq through sysfs and then running cpuburn-a53 on each available cpufreq at least for a few minutes? Something like that: echo 120000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq cpuburn-a53 & for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies); do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq sleep 600 done pkill cpuburn-a53 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 so the regulator can't go lower than 1V and all OPPs that reference <1V are discarded. The regulator should be lowered to 940000 indeed, but the Cooling table also needs some adjustments. Lets select all the entries for the warm and hot entry and limit very hot to the last or so 5 entries? 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 Created a small tool that checks the stability of a range of frequencies using HPL. Simple clone the git and install libmpich-dev and you're good to go. https://github.com/ehoutsma/StabilityTester If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in. Edit: Don't be scared of high temperatures! High temperatures are good! 3 Quote
zador.blood.stained Posted January 27, 2017 Posted January 27, 2017 Does anyone have any problems with rebooting the board? For me it sometimes hangs in/after the SPL. 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 Yup, I have a reproducable error when rebooting. If I lower the frequency and with that the core voltage it hangs on trying to boot MMC1. Either we need to increase the voltage when rebooting or add a driver to SPL that sets the correct voltage. 0 Quote
hojnikb Posted January 27, 2017 Posted January 27, 2017 Created a small tool that checks the stability of a range of frequencies using HPL. Simple clone the git and install libmpich-dev and you're good to go. https://github.com/ehoutsma/StabilityTester If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in. Edit: Don't be scared of high temperatures! High temperatures are good! Thank you for the tool! Here are my results. I had a fan blowing directly to the SoC (no heatsink yet) just to let it run at highest possible frequency without throttling. root@orangepipc2:/home/benhjamin/StabilityTester# ./stabilityTester.sh Testing frequency 792000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 816000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 864000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 912000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 936000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 960000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1008000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1056000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1080000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1104000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1152000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Testing frequency 1200000 Cooling down./stabilityTester.sh: line 78: echo: write error: Invalid argument Cooling down: 54123 Done testing stability: Frequency: 792000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 816000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 864000 Voltage: 1040000 Success: 1 Result: 0.0048034 Frequency: 912000 Voltage: 1050000 Success: 1 Result: 0.0048034 Frequency: 936000 Voltage: 1060000 Success: 1 Result: 0.0048034 Frequency: 960000 Voltage: 1080000 Success: 1 Result: 0.0048034 Frequency: 1008000 Voltage: 1100000 Success: 1 Result: 0.0048034 Frequency: 1056000 Voltage: 1150000 Success: 1 Result: 0.0048034 Frequency: 1080000 Voltage: 1160000 Success: 1 Result: 0.0048034 Frequency: 1104000 Voltage: 1170000 Success: 1 Result: 0.0048034 Frequency: 1152000 Voltage: 1200000 Success: 1 Result: 0.0048034 Frequency: 1200000 Voltage: 1240000 Success: 1 Result: 0.0048034 0 Quote
zador.blood.stained Posted January 27, 2017 Posted January 27, 2017 I would say that adding a driver to the SPL is more reliable since it would work in case of a kernel crash. Some boards like Cubietruck already use I2C in SPL to communicate with the PMIC. Edit: Done testing stability: Frequency: 648000 Voltage: 970000 Success: 1 Result: 0.0048034 Frequency: 672000 Voltage: 970000 Success: 1 Result: 0.0048034 Frequency: 720000 Voltage: 970000 Success: 1 Result: 0.0048034 Frequency: 768000 Voltage: 980000 Success: 1 Result: 0.0048034 Frequency: 792000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 816000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 864000 Voltage: 1040000 Success: 1 Result: 0.0048034 Frequency: 912000 Voltage: 1050000 Success: 1 Result: 0.0048034 Frequency: 936000 Voltage: 1060000 Success: 1 Result: 0.0048034 Frequency: 960000 Voltage: 1080000 Success: 1 Result: 0.0048034 Frequency: 1008000 Voltage: 1100000 Success: 1 Result: 0.0048034 Frequency: 1056000 Voltage: 1150000 Success: 1 Result: 0.0048034 Frequency: 1080000 Voltage: 1160000 Success: 1 Result: 0.0048034 Frequency: 1104000 Voltage: 1170000 Success: 1 Result: 0.0048034 Frequency: 1152000 Voltage: 1200000 Success: 1 Result: 0.0048034 Frequency: 1200000 Voltage: 1240000 Success: 1 Result: 0.0048034 Edit 2: You don't need a SYxxx regulator driver, just one I2C write to set the voltage and maybe an I2C read to confirm that it was set, but you'll need a H3 compatible I2C controller driver if it is not present already. 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 I would say that adding a driver to the SPL is more reliable since it would work in case of a kernel crash. Some boards like Cubietruck already use I2C in SPL to communicate with the PMIC. I'm currently looking into it. Edit: There is a driver for SY8106A in mainline, so it should be simple. 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 I've sent a patch to enable the SY8106A driver in SPL. 2 Quote
willmore Posted January 27, 2017 Posted January 27, 2017 My PC2 ran 24 hours of cpuminer on four cores. No crashes, no syslog entries that indicate anything is wrong. Temps 70-75C. Clock speeds 1056/1080MHz. Hashes between 3.2 and 3.3KH/s. No heatsink. No fan. Board in a slightly enclosed space with no additional airflow enhancements. Image from 20170127. I'll reboot to the new kernel and try xhpl and/or Linpac. 1 Quote
tkaiser Posted January 27, 2017 Posted January 27, 2017 Clock speeds 1056/1080MHz. Hashes between 3.2 and 3.3KH/s. No heatsink. No fan. Very nice As a comparison: With Pine64 I got 3.9 khash/s at 1296 MHz (with heatsink and IIRC 2 fans). So performance of CPU cores in A64 and H5 is identical but Xunlong did again a great job regarding heat dissipation. Pine64 also uses the ground plane as heatsink but if I remember correctly I got these values on my Pine64 without heatsinks: http://linux-sunxi.org/File:Testing_throttling_and_performance_behaviour_on_Pine64.png @willmore: Would be interesting sometimes later to compare with Pine64 (can't do myself due to both boards in a test setup a few hundred km away). But now stability testing through different DVFS operating points is more interesting. Would be great to let something loop through all available cpufreqs as outlined in #129 above and test with cpuburn-a53, cpuminer and ErwinH's stabilityTester.sh (after applying latest fixes from build system to also walk through the lowest operating points) 1 Quote
willmore Posted January 27, 2017 Posted January 27, 2017 @tkaiser: Of course. I have a Pine64 as well. I'd be glad to run any testing on it that you'd like. I haven't had it up and running in a while, so I may need to run a few updates to get it current. What particular setup would you like me to test? Oh, my Pine64 also does not have a heatsink--it, like the PC2 are completely stock. I'm very impressed with both the PC2 and the work that all of you have done to get armbian running this well on it this quickly. Thank you. 0 Quote
tkaiser Posted January 27, 2017 Posted January 27, 2017 What particular setup would you like me to test? For now as already outlined just the DVFS stuff for OPi PC2. And if there's some time later you might try out cpuminer with identical 'environmental' conditions as OPi PC2 just to get an idea how efficient both board designs are regarding heat dissipation through the lower BGA side using the board itself as huge heatsink. But for me personally current status with H5, OPi PC2 and the other announced new devices (mainline kernel, +1.3GHz available, GbE working, count of USB2 ports, price including shipping) means almost every A64 design is already 'dead'/uninteresting now. So there's no need to rush with such comparisons 1 Quote
willmore Posted January 27, 2017 Posted January 27, 2017 @tkiser Okay, so I'll run the script from #129 and record temps? Or just run it and see if the machine fails in some way? 0 Quote
Christos Posted January 27, 2017 Author Posted January 27, 2017 @zador.blood.stained It looks that the latest builds (Ubuntu desktop) give a very good result and stable operation as tested with my own DSP application here. Tried a few reboots and had no issues, though I see some strange reporting in the tty console Unmounting /var/log... [FAILED] Failed unmounting /tmp. [ OK ] Unmounted /run/user/1000. [ OK ] Unmounted /var/log.hdd. [FAILED] Failed unmounting /var/log. [ OK ] Reached target Unmount All Filesystems. [ OK ] Stopped target Local File Systems (Pre). [ OK ] Stopped Remount Root and Kernel File Systems. [ OK ] Stopped Create Static Device Nodes in /dev. [ OK ] Started Unattended Upgrades Shutdown. [ OK ] Reached target Shutdown. [ 82.195445] reboot: Power down INFO: PSCI Affinity Map: INFO: AffInst: Level 0, MPID 0x0, State ON INFO: AffInst: Level 0, MPID 0x1, State ON INFO: AffInst: Level 0, MPID 0x2, State ON INFO: AffInst: Level 0, MPID 0x3, State ON ERROR: PSCI system shutdown: still alive ... And this is where it stops but the message is strange to me. Just reporting it FYI. OOOOoooops!! As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!! I had the tty already connected and this is the remaining output U-Boot SPL 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:53:59) DRAM: 1024 MiB Trying to boot from MMC1NOTICE: BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):cd7fa48 NOTICE: BL3-1: Built : 13:53:22, Jan 27 2017 NOTICE: PLL_CPUX: 90001410 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2017.01-rc1-g5df570f-dirty (Jan 27 2017 - 13:57:55 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi PC 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment HDMI connected: Setting up a 1920x1080 hdmi console (overscan 0x0) hdmi enabled In: serial Out: vga Err: vga Net: phy interface7 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1768 bytes read in 176 ms (9.8 KiB/s) ## Executing script at 4fc00000 Boot script loaded from mmc 91 bytes read in 148 ms (0 Bytes/s) 24310 bytes read in 263 ms (89.8 KiB/s) 4222403 bytes read in 437 ms (9.2 MiB/s) 11261960 bytes read in 659 ms (16.3 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 4222339 Bytes = 4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 49bf9000, end 49fffd83 ... OK Loading Device Tree to 0000000049bf0000, end 0000000049bf8ef5 ... OK Starting kernel ... Loading, please wait... starting version 229 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems [ 2.403476] thermal thermal_zone0: critical temperature reached(132 C),shutting down done. Begin: Will now check root file system ... fsck from util-linux 2.27.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 184517/954720 files, 1211259/3811232 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. [ 2.751503] thermal thermal_zone0: critical temperature reached(132 C),shutting down [ 2.939899] reboot: Power down INFO: PSCI Affinity Map: INFO: AffInst: Level 0, MPID 0x0, State ON INFO: AffInst: Level 0, MPID 0x1, State ON INFO: AffInst: Level 0, MPID 0x2, State ON INFO: AffInst: Level 0, MPID 0x3, State ON ERROR: PSCI system shutdown: still alive ... At that stage I unplugged the power.. hope this info helps 0 Quote
tkaiser Posted January 27, 2017 Posted January 27, 2017 @tkiser Okay, so I'll run the script from #129 and record temps? Or just run it and see if the machine fails in some way? Please keep an eye on actual cpufreq ('sudo armbianmonitor -m' in another shell) since without a heatsink testing through the upper DVFS operating points is pointless. This is more about the lower ones and as soon as throttling jumps in you can stop the test. 0 Quote
hojnikb Posted January 27, 2017 Posted January 27, 2017 yeah, i had the same issue when i bumped up Ns to 8192. Frequencies above ~900Mhz simply reach throttling points before stress test is complete. Have to rig up a heatsink and a decent fan to properly test all of them (btw, can frequencies even go above 1300Mhz ?) 0 Quote
ErwinH Posted January 27, 2017 Posted January 27, 2017 The highest frequency I was able to test and get a valid result was 1368MHz at 1400 mV. It ran a little over 95C. 0 Quote
Christos Posted January 27, 2017 Author Posted January 27, 2017 Did another build with latest commits. Non-booting problem again. Latest commit that was working ok was commit dc6f9d9, with commits after that it stopped booting properly and go into endless reboots. 0 Quote
zador.blood.stained Posted January 27, 2017 Posted January 27, 2017 Have to rig up a heatsink and a decent fan to properly test all of them (btw, can frequencies even go above 1300Mhz ?) The max frequency is probably limited in /etc/default/cpufrequtils OOOOoooops!! As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!! I had the tty already connected and this is the remaining output Hm. Critical temperature is set to 110°C, and I noticed these PSCI messages too when shutting down, but I usually cut the power right after shutdown. 0 Quote
zador.blood.stained Posted January 27, 2017 Posted January 27, 2017 Non-booting problem again. Latest commit that was working ok was commit dc6f9d9, with commits after that it stopped booting properly and go into endless reboots. Works for me 0 Quote
Christos Posted January 27, 2017 Author Posted January 27, 2017 Works for me For you it was already working from the start. If you remember there was the pullup issue for some.. P.S. I'm performing another build, just in case something went wrong before.. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.