03-01-2016, 01:57 PM
(This post was last modified: 03-01-2016, 02:00 PM by rubenk.)
We are currently using a very expensive but low-power arm sbc for long term field monitoring and control (embedded hardware). Has anybody looked into how low the power could go if we turned off power to the accessories that wouldn't be needed like HDMI video to audio in and out, SATA, camera, things like that? I think we could even get by with running on a single core. This is probably far outside of the intended audience of the board but that is our application and I thought I would ask.
One thing that is a definite kick in the nuz is that there is no onboard eMMC. I have plans to keep this in the field for months at a time even up to a year between service intervals. I'd rather have one place to store the data and another place to boot the OS but such is life. There is an ODROID board that allows you to have onboard be MMC but I don't know very much about it or about power consumption.
So, the final question: is it an ill-fated attempt to try to take the power out of the pine 64? If so, does anybody have any recommendations?
BTW power on our current board is about 0.5 Watts at idle
(03-01-2016, 01:57 PM)rubenk Wrote: We are currently using a very expensive but low-power arm sbc for long term field monitoring and control (embedded hardware). Has anybody looked into how low the power could go if we turned off power to the accessories that wouldn't be needed like HDMI video to audio in and out, SATA, camera, things like that? I think we could even get by with running on a single core. This is probably far outside of the intended audience of the board but that is our application and I thought I would ask.
One thing that is a definite kick in the nuz is that there is no onboard eMMC. I have plans to keep this in the field for months at a time even up to a year between service intervals. I'd rather have one place to store the data and another place to boot the OS but such is life. There is an ODROID board that allows you to have onboard be MMC but I don't know very much about it or about power consumption.
So, the final question: is it an ill-fated attempt to try to take the power out of the pine 64? If so, does anybody have any recommendations?
BTW power on our current board is about 0.5 Watts at idle
Actually, the eMMC module can be build on the Wifi/BT connector thru SDIO 3.0 bus which is also SD bus that suitable for eMMC. We are currently explore into this path which server application don't use Wifi/BT module. Noted that there is only 4bit bus and the access speed is slower. On idle mode, the Pine A64 board goes below 0.5 watt. My guess single core headless operation runs about 2 watts.
03-01-2016, 04:10 PM
(This post was last modified: 03-01-2016, 04:25 PM by rubenk.)
[quote pid='2919' dateline='1456868988']
Actually, the eMMC module can be build on the Wifi/BT connector thru SDIO 3.0 bus which is also SD bus that suitable for eMMC. We are currently explore into this path which server application don't use Wifi/BT module. Noted that there is only 4bit bus and the access speed is slower. On idle mode, the Pine A64 board goes below 0.5 watt. My guess single core headless operation runs about 2 watts.
[/quote]
So I want to make sure that I read this correctly. In its deepest sleep state it can consume as low as 0.5 once but if I am running a process it consumes 2.0 Watts but that is only on one core. How much does it consume with all four cores? Just curious.
I just wanted to make sure you didn't make a typo.
Also, good to hear about the idea of a POT or TOP (or whatever) eMMC. Some of the value is removed by it being slower than microsd rather than faster but it definitely serves the purpose I described!
(03-01-2016, 04:10 PM)rubenk Wrote: [quote pid='2919' dateline='1456868988']
Actually, the eMMC module can be build on the Wifi/BT connector thru SDIO 3.0 bus which is also SD bus that suitable for eMMC. We are currently explore into this path which server application don't use Wifi/BT module. Noted that there is only 4bit bus and the access speed is slower. On idle mode, the Pine A64 board goes below 0.5 watt. My guess single core headless operation runs about 2 watts.
So I want to make sure that I read this correctly. In its deepest sleep state it can consume as low as 0.5 once but if I am running a process it consumes 2.0 Watts but that is only on one core. How much does it consume with all four cores? Just curious.
I just wanted to make sure you didn't make a typo.
Also, good to hear about the idea of a POT or TOP (or whatever) eMMC. Some of the value is removed by it being slower than microsd rather than faster but it definitely serves the purpose I described!
[/quote]
Oh. Looked like about 5v at 2amps? 10 watts. Wow
(03-01-2016, 04:10 PM)rubenk Wrote: [quote pid='2919' dateline='1456868988']
Actually, the eMMC module can be build on the Wifi/BT connector thru SDIO 3.0 bus which is also SD bus that suitable for eMMC. We are currently explore into this path which server application don't use Wifi/BT module. Noted that there is only 4bit bus and the access speed is slower. On idle mode, the Pine A64 board goes below 0.5 watt. My guess single core headless operation runs about 2 watts.
So I want to make sure that I read this correctly. In its deepest sleep state it can consume as low as 0.5 once but if I am running a process it consumes 2.0 Watts but that is only on one core. How much does it consume with all four cores? Just curious.
I just wanted to make sure you didn't make a typo.
Also, good to hear about the idea of a POT or TOP (or whatever) eMMC. Some of the value is removed by it being slower than microsd rather than faster but it definitely serves the purpose I described!
(03-01-2016, 04:10 PM)rubenk Wrote: [quote pid='2919' dateline='1456868988']
Actually, the eMMC module can be build on the Wifi/BT connector thru SDIO 3.0 bus which is also SD bus that suitable for eMMC. We are currently explore into this path which server application don't use Wifi/BT module. Noted that there is only 4bit bus and the access speed is slower. On idle mode, the Pine A64 board goes below 0.5 watt. My guess single core headless operation runs about 2 watts.
So I want to make sure that I read this correctly. In its deepest sleep state it can consume as low as 0.5 once but if I am running a process it consumes 2.0 Watts but that is only on one core. How much does it consume with all four cores? Just curious.
I just wanted to make sure you didn't make a typo.
Also, good to hear about the idea of a POT or TOP (or whatever) eMMC. Some of the value is removed by it being slower than microsd rather than faster but it definitely serves the purpose I described!
[/quote]
Oh. Looked like about 5v at 2amps? 10 watts. Wow
[/quote]
Deep sleep consumes much lower than 0.5W. The power supply listed 5V 2amp due to factor in USB power consumption and also power consumption surge.
Just to clear things up for others, there's a big difference between idle and deep sleep mode.
Idle is the state the kernel goes into when there's nothing else to do (all tasks are waiting for something like I/O or sleeping). The kernel executes a "wait for interrupt" instruction on each core, which allows the ARM cores to go into the lowest possible power mode while still running the clock. At this point, or shortly afterwards if the CPU governor allows, the CPU clock speed drops to its minimum, 480MHz on the Pine64. Even though the clock is still running, the CPU cores consume less power than they would if they were executing NOPs in a loop. The Pine64 sitting on my desk here is currently consuming 90mA (.45W) at 480MHz idle, ethernet powered down, HDMI disconnected (but not necessarily powered down). Increasing the CPU clock to 1.152 GHz causes the current consumption at idle to rise to 110Ma. Depending on the kernel and SoC, other parts of the chip may switch into lower power modes when in the idle state, e.g., the DRAM bus and GPU clock speed will typically be reduced as well.
Deep sleep mode is an entirely different state. The clocks to most of the SoC are disabled (in Arm parlance, they are "gated"), DRAM is put into self-refresh mode, and the only things left running are a low speed timer (for timer wakeup events), the interrupt controller (although most of its inputs may also be gated), and the interrupt lines for things that are allowed to wake up the SoC, e.g., network devices, touch controllers, the power button gpio, and the low speed timer. The kernel only enters deep sleep mode on demand, when something makes the request_suspend_state call (at least this is how it's done in android kernels -- not sure if this is also in mainline). I don't have the android distro on a card ATM, so I can't measure the Pine64's current draw in deep sleep mode, but on the Freescale iMX6 DualLite, the current draw in DSM for a 1GB board is around 15mA.
Just for fun, I ran a single instance of nbench, which runs the CPU up close to 100%. Consumption wend up to 180mA. Of course, this probably doesn't fully load the CPU core, as the Cortex-A53 can issue multiple integer and floating point instructions in a single cycle, so you'd need an artificial test that interleaved integer and floating point operations just right to max out a core. But assuming you wouldn't normally max out a single core, you should be fine on a budget of less than 1 watt for busy periods and less than .5 watt for idle.
Running a second nbench pushed the current draw to between 250 and 280mA, but also caused thermal throttling to kick in and reduce the clock speed to 1.1GHz (it did cycle up and down between 1.152 and 1.1GHz during this test, which may also explain why the current usage fluctuated much more than in the case of a single nbench instance).
(03-02-2016, 02:48 PM)patrickhwood Wrote: Just to clear things up for others, there's a big difference between idle and deep sleep mode.
Idle is the state the kernel goes into when there's nothing else to do (all tasks are waiting for something like I/O or sleeping). The kernel executes a "wait for interrupt" instruction on each core, which allows the ARM cores to go into the lowest possible power mode while still running the clock. At this point, or shortly afterwards if the CPU governor allows, the CPU clock speed drops to its minimum, 480MHz on the Pine64. Even though the clock is still running, the CPU cores consume less power than they would if they were executing NOPs in a loop. The Pine64 sitting on my desk here is currently consuming 90mA (.45W) at 480MHz idle, ethernet powered down, HDMI disconnected (but not necessarily powered down). Increasing the CPU clock to 1.152 GHz causes the current consumption at idle to rise to 110Ma. Depending on the kernel and SoC, other parts of the chip may switch into lower power modes when in the idle state, e.g., the DRAM bus and GPU clock speed will typically be reduced as well.
Deep sleep mode is an entirely different state. The clocks to most of the SoC are disabled (in Arm parlance, they are "gated"), DRAM is put into self-refresh mode, and the only things left running are a low speed timer (for timer wakeup events), the interrupt controller (although most of its inputs may also be gated), and the interrupt lines for things that are allowed to wake up the SoC, e.g., network devices, touch controllers, the power button gpio, and the low speed timer. The kernel only enters deep sleep mode on demand, when something makes the request_suspend_state call (at least this is how it's done in android kernels -- not sure if this is also in mainline). I don't have the android distro on a card ATM, so I can't measure the Pine64's current draw in deep sleep mode, but on the Freescale iMX6 DualLite, the current draw in DSM for a 1GB board is around 15mA.
Just for fun, I ran a single instance of nbench, which runs the CPU up close to 100%. Consumption wend up to 180mA. Of course, this probably doesn't fully load the CPU core, as the Cortex-A53 can issue multiple integer and floating point instructions in a single cycle, so you'd need an artificial test that interleaved integer and floating point operations just right to max out a core. But assuming you wouldn't normally max out a single core, you should be fine on a budget of less than 1 watt for busy periods and less than .5 watt for idle.
Running a second nbench pushed the current draw to between 250 and 280mA, but also caused thermal throttling to kick in and reduce the clock speed to 1.1GHz (it did cycle up and down between 1.152 and 1.1GHz during this test, which may also explain why the current usage fluctuated much more than in the case of a single nbench instance). Thanks on the clear explanation.
... TL
(03-02-2016, 02:48 PM)patrickhwood Wrote: Just to clear things up for others, there's a big difference between idle and deep sleep mode.
Idle is the state the kernel goes into when there's nothing else to do (all tasks are waiting for something like I/O or sleeping). The kernel executes a "wait for interrupt" instruction on each core, which allows the ARM cores to go into the lowest possible power mode while still running the clock. At this point, or shortly afterwards if the CPU governor allows, the CPU clock speed drops to its minimum, 480MHz on the Pine64. Even though the clock is still running, the CPU cores consume less power than they would if they were executing NOPs in a loop. The Pine64 sitting on my desk here is currently consuming 90mA (.45W) at 480MHz idle, ethernet powered down, HDMI disconnected (but not necessarily powered down). Increasing the CPU clock to 1.152 GHz causes the current consumption at idle to rise to 110Ma. Depending on the kernel and SoC, other parts of the chip may switch into lower power modes when in the idle state, e.g., the DRAM bus and GPU clock speed will typically be reduced as well.
Deep sleep mode is an entirely different state. The clocks to most of the SoC are disabled (in Arm parlance, they are "gated"), DRAM is put into self-refresh mode, and the only things left running are a low speed timer (for timer wakeup events), the interrupt controller (although most of its inputs may also be gated), and the interrupt lines for things that are allowed to wake up the SoC, e.g., network devices, touch controllers, the power button gpio, and the low speed timer. The kernel only enters deep sleep mode on demand, when something makes the request_suspend_state call (at least this is how it's done in android kernels -- not sure if this is also in mainline). I don't have the android distro on a card ATM, so I can't measure the Pine64's current draw in deep sleep mode, but on the Freescale iMX6 DualLite, the current draw in DSM for a 1GB board is around 15mA.
Just for fun, I ran a single instance of nbench, which runs the CPU up close to 100%. Consumption wend up to 180mA. Of course, this probably doesn't fully load the CPU core, as the Cortex-A53 can issue multiple integer and floating point instructions in a single cycle, so you'd need an artificial test that interleaved integer and floating point operations just right to max out a core. But assuming you wouldn't normally max out a single core, you should be fine on a budget of less than 1 watt for busy periods and less than .5 watt for idle.
Running a second nbench pushed the current draw to between 250 and 280mA, but also caused thermal throttling to kick in and reduce the clock speed to 1.1GHz (it did cycle up and down between 1.152 and 1.1GHz during this test, which may also explain why the current usage fluctuated much more than in the case of a single nbench instance).
Patrick, is the "Deep Sleep" drivers available in the Pine64 distributions? Also, what type of wake up times we should expect?
03-18-2016, 09:40 AM
(This post was last modified: 03-18-2016, 09:40 AM by patrickhwood.)
Deep sleep mode (DSM) is a standard feature in linux for some time. It's used more by android than your typical desktop distribution, but all modern linux kernels should support it. That said, power savings haven't been a priority for me on the Pine64, so I can't say to what extent it's supported without user intervention. For example, phones and tablets running android all support some level of DSM and go into this mode automatically after a timeout; a headless linux on the Pine64 may require a userland program and some kernel patches to support going into DSM and coming out based on an IRQ or timer event.
My experience with DSM is on Freescale iMX6 processors, so the times may be a little different, but on a 1GHz Cortex A9 it takes about 500 usec to exit DSM and another 150 msec to restart all the device drivers and get to the point of processing interrupts and running userland processes again.
How can we put pine64 android version to Deepsleep?
I don't know very much about it or about power consumption
คาสิโน sbobet
|
