Jump to content


Photo

Running H3 boards with minimal consumption


37 replies to this topic

#31 nematocyst

nematocyst

    Newbie

  • Senior Members
  • Pip
  • 6 posts

Posted 26 August 2016 - 06:16 PM

If DRAM clockspeed influences your application or not I don't know -- maybe you don't know too since you never tested it? In case it has a benchmark mode, adjust DRAM clockspeed and re-test 

 

That's a good point.  I suspected it did, but wasn't sure.  I tested it as you suggested and indeed it does-- the engine does have a benchmark mode.

 

The h3consumption utility seems to work well.  I disabled hdmi, usb, and reduced cores to 2, all without issue.  I can't measure actual consumption though.  The only indicator is I can look at the trends in armbianmonitor to see if there's improvement.

 

Also, I got an error when trying to lower DRAM settings.  It seemed to work, as evidenced by the speed reduction on the benchmark test, however there was no /etc/armbian-release, spitting out an error.  It seems I'm still running 5.11.  heh.  I'm not anxious to update, but the next release I will make myself do it, since I suspect the one I'm running has that awful allwinner root exploit.  Actually... I guess waiting doesn't really matter since after 5.15? apt-get upgrade is all one needs to do.  My issue is using a fresh image, but no way around that.  It's just I have it working nicely already.



#32 WarHawk_AVG

WarHawk_AVG

    Newbie

  • Senior Members
  • Pip
  • 9 posts

Posted 06 September 2016 - 07:54 AM

Nice tkaiser, now all is needed is a script to bring the other cpu's online load dependent...very cool!



#33 tkaiser

tkaiser

    Advanced Member

  • Moderators
  • 2842 posts

Posted 06 September 2016 - 08:36 AM

Nice tkaiser, now all is needed is a script to bring the other cpu's online load dependent...very cool!

 

No. Please read through post #25 of this thread again. You have to differentiate between idle and peak/full consumption. Shutting down CPU cores does only help with the latter and idle CPU cores do not add to consumption that much or at all (especially when you have in mind that all these numbers are without taking the PSU into account. Most SBC PSUs are inefficient crap and you get way more savings by looking at the PSU instead of the board. This whole consumption issue is more or less with special use cases in mind where you power IoT devices from battery or deal with a fleet of devices and want to calculate your PSU dimensions -- 'one PSU to feed them all', in wired IoT scenarios with Fast Ethernet normally passive PoE with one large PSU is used).

 

Again: it's absolutely useless shutting down CPU cores when it's about idle consumption:

  • Limit count of CPU cores to 1 -30 mW: -c 1 (affects only peak/full consumption)

  • WarHawk_AVG and willmore like this

Please don't send personal messages! Use the forum so others can participate and benefit!

 

Before you report any problem please be aware that crappy SD cards and insufficient power supply are reason N° 1 why things are failing. Try to rule this out first please, check 'getting started' recommendations and check/provide 'sudo armbianmonitor -u' output first!

 

Did you check out custom google powered forum search already (before opening new threads or asking questions)?


#34 abramq

abramq

    Member

  • Senior Members
  • PipPip
  • 21 posts

Posted 17 February 2017 - 02:22 PM

Hello,
Sorry if my question is inopportune - would be possible to change all that appropriate parameters on-line, when system is working?
I mean my Orange Pi is working on very low gears, waiting for a signal (from smartphone via WiFi or BT). When the signal comes, Orange Pi switch gear up and performs important tasks (that need more power). Then a signal again and lower gear :-)
Could be very good way to make boards smarter :-)

#35 reverend_t

reverend_t

    Member

  • Senior Members
  • PipPip
  • 18 posts

Posted 17 February 2017 - 03:06 PM

To be honest that's what the CPU governors do, for CPU speeds at least. It's possible to take this approach further and have specialised cores just for idling (I think some Allwinner chips use Cortex M cores for this purpose) but that's not something that the H series has. 



#36 jernej

jernej

    Advanced Member

  • Senior Members
  • PipPipPip
  • 446 posts

Posted 17 February 2017 - 04:44 PM

Well, H series and at least A64 has OpenRISC coprocessor. BSP kernel use it for at least suspend and waking up processor again. For example, it monitors IR sensor and if right command is received, it wakes up the main ARM cores.



#37 reverend_t

reverend_t

    Member

  • Senior Members
  • PipPip
  • 18 posts

Posted 18 February 2017 - 12:50 PM

Ha, great! I'd forgotten the set-top box heritage of these chips :D

 

Is this something supported on Armbian (legacy or mainline)?



#38 jernej

jernej

    Advanced Member

  • Senior Members
  • PipPipPip
  • 446 posts

Posted 18 February 2017 - 01:23 PM

It is supported on legacy. OpenRISC core is not used on mainline (yet) but there is some code on the net, which is enough to start playing with it. Of course, suspend/resume is not yet supported on mainline.