Measuring 30b CPU speed reduction

[Csaba Tizedes]

In the HP 20b/30b manual (Programming - Page 82) I found an interesting information about CPU speed: "If a program takes more than one second to run, the CPU speed will be reduced in order to preserve battery life."

Wow, it's interesting - but what is the percentage of this reduction? I decided I will measure it and I think I found a very simple method (pls. check the inserted image below):


The measured ratio was 1/5.57, therefore the CPU speed reduced from 100% to 18%.
Have you got any information about the right value?
What do you think about the measuring method (counting - before running program at point 1., you need to fill up the stack with 1's: 1 [ENTER] [ENTER] [ENTER])?

Csaba

[Thomas Radtke]

Makes as much sense as a car reducing its speed from 100 to 18 km/h after some time to conserve fuel (I see an EU regulation coming). Works, but is maybe not in the best interest of the driver/programmer.

[Sukiari]

Thanks for this information. These types of posts keep me coming back for more.

Is there any way to override this behavior?

[Csaba Tizedes]

(08-01-2015 06:01 PM)Sukiari Wrote:  Thanks for this information. These types of posts keep me coming back for more.

Is there any way to override this behavior?

Thanks - but I need a feedback from an expert about the right value.
From the measured data clearly shown the intersection of curve with y-axis is not equal with zero (intersection at b=3745), therefore the speed of CPU is changed during program execution (if no change in CPU speed the intersection is at b=0, because the counter value is proportional with running time).

How you can override it? Write tiny programs with short running times only.
BTW: the 30b far the fastest programmable calculator on the HP market I think.

Csaba

[Gene]

The 20b/30b have a "test mode" which if I recall correctly makes the processor stay at full speed... and full consumption of the batteries...

Mentioned in places such as this: Test mode thread

[cyrille de brébisson]

Hello,

I do not remember exactly the values for the CPU, but I am the one who implemented the feature and can explain the why of it and why it does actually preserve battery life (Car analogy is incorrect)...

At full speed (30~36Mhz), the CPU will draw around 20mA. This is outside the normal operating range for CR2032 for 'long pulse' and result is a rapid rise of the battery internal resistance, and hence a lot of energy wasted 'in the battery'.

CR2032 are OK with short pulses of high power draw, but can not (are not designed) to sustend continuous high power draw. They are OK with a continuous low power draw however.

So, if the calculator runs for more than 1s at full speed, a timer kicks in and reduces CPU speed to 4Mhz (from memory). At that speed, the CPU runs on an internal oscillator which is very power friendly (compared with the PLL used at 30Mhz), AND the wait state of the flash can be reduced to 0 (instead of one, which speeds up the CPU calculation compared with the CPU speed).

This reduces the power consumption by a factor much greater than the ~5 time drop in CPU speed (around 10 if my memory serves me well) and places the batter draw back in the 'long pulse' range, drops the battery internal resistance (which means that battery energy will be used by the CPU and not to heat up the battery), and in turn increase battery life...

So, the correct car analogy is to say that driving a car at 20Mph DOES save gaz compared with driving it at 200Mph (which is certainly true as the wind resistance is non linear!)

I hope that this helps!

Cyrille

[Sukiari]

(08-03-2015 05:05 AM)cyrille de brébisson Wrote:  Hello,

I do not remember exactly the values for the CPU, but I am the one who implemented the feature and can explain the why of it and why it does actually preserve battery life (Car analogy is incorrect)...

At full speed (30~36Mhz), the CPU will draw around 20mA. This is outside the normal operating range for CR2032 for 'long pulse' and result is a rapid rise of the battery internal resistance, and hence a lot of energy wasted 'in the battery'.

CR2032 are OK with short pulses of high power draw, but can not (are not designed) to sustend continuous high power draw. They are OK with a continuous low power draw however.

So, if the calculator runs for more than 1s at full speed, a timer kicks in and reduces CPU speed to 4Mhz (from memory). At that speed, the CPU runs on an internal oscillator which is very power friendly (compared with the PLL used at 30Mhz), AND the wait state of the flash can be reduced to 0 (instead of one, which speeds up the CPU calculation compared with the CPU speed).

This reduces the power consumption by a factor much greater than the ~5 time drop in CPU speed (around 10 if my memory serves me well) and places the batter draw back in the 'long pulse' range, drops the battery internal resistance (which means that battery energy will be used by the CPU and not to heat up the battery), and in turn increase battery life...

So, the correct car analogy is to say that driving a car at 20Mph DOES save gaz compared with driving it at 200Mph (which is certainly true as the wind resistance is non linear!)

I hope that this helps!

Cyrille

Thank you for your excellent explanation. It is really great to find out exactly what is going on with one's machine!

What do you suppose the slow and fast speeds of the WP-34S firmware do to the battery? I always run mine with the slow setting by the way.

[Csaba Tizedes]

(08-03-2015 05:05 AM)cyrille de brébisson Wrote:  So, if the calculator runs for more than 1s at full speed, a timer kicks in and reduces CPU speed to 4Mhz (from memory). At that speed, the CPU runs on an internal oscillator which is very power friendly (compared with the PLL used at 30Mhz), AND the wait state of the flash can be reduced to 0 (instead of one, which speeds up the CPU calculation compared with the CPU speed).

This reduces the power consumption by a factor much greater than the ~5 time drop in CPU speed (around 10 if my memory serves me well) and places the batter draw back in the 'long pulse' range, drops the battery internal resistance (which means that battery energy will be used by the CPU and not to heat up the battery), and in turn increase battery life...

So, as I understand - after 1 sec continous running::
1.) The CPU speed reduced from 30~36MHz to 4MHz (factor_1: 1÷(7.5 ... 9))
2.) CPU calculation speed increasing (wait state reduction) (factor_2: (5 ... 10) ???)

The second point factor_2=(5 ... 10) is the factor of power consumption increasing or this is the factor of speed increasing (please translate your explanation to the simplified English )

Csaba

[Thomas Radtke]

(08-03-2015 05:05 AM)cyrille de brébisson Wrote:  [...] (Car analogy is incorrect)...

This reduces the power consumption by a factor much greater than the ~5 time drop in CPU speed [...]

So, the correct car analogy is to say that driving a car at 20Mph DOES save gaz compared with driving it at 200Mph

This is math from a different universe. 200/5 = 40 or 100/5 = 20. Close to what Csaba got and hence my analogy was:

Quote:[...] a car reducing its speed from 100 to 18 km/h

I meant no offense. Just didn't knew the underclocked CPU was more efficient.

Have I missed something?

[Paul Dale]

(08-03-2015 05:16 AM)Sukiari Wrote:  What do you suppose the slow and fast speeds of the WP-34S firmware do to the battery? I always run mine with the slow setting by the way.

Marcus is the person to ask about this since he implemented the various speeds. I almost always use SLOW mode and once the battery voltage drops far enough, the 34S always runs in SLOW mode regardless of what you specify. Our low voltage handling seems to have a few quirks which have surprised people


My guess is that for normal (non-program) execution, it won't make too much difference. The CPU generally doesn't run for very long before returning to the low power idle states (we use two I think but it might be more). There are exceptions of course (some of the statistical functions being the main ones I'm aware of).

When running a program, SLOW mode will stress the battery less for the reasons Cyrille gave, although it isn't backing off anything like as far as the 30b does.


In light of Cyrille's comment, there is possibly some room for improvement in the 34S firmware -- slowing the clock down during a long run seems sensible -- this is trading battery life for performance but not in a linear fashion.


I don't remember Marcus mentioning anything about dynamically changing the wait state setting. The 34S seems to always use one wait state currently. SLOW mode on the 34S is 20MHz which is too fast to reduce the number of wait states (15MHz is upper limit for zero wait states according to the data sheet), however making SLOW mode 15MHz and getting rid of the wait states might be a win.


- Pauli

[Claudio L.]

(08-09-2015 11:52 AM)Thomas Radtke Wrote:  

(08-03-2015 05:05 AM)cyrille de brébisson Wrote:  [...] (Car analogy is incorrect)...

This reduces the power consumption by a factor much greater than the ~5 time drop in CPU speed [...]

So, the correct car analogy is to say that driving a car at 20Mph DOES save gaz compared with driving it at 200Mph

This is math from a different universe. 200/5 = 40 or 100/5 = 20. Close to what Csaba got and hence my analogy was:

Quote:[...] a car reducing its speed from 100 to 18 km/h

I meant no offense. Just didn't knew the underclocked CPU was more efficient.

Have I missed something?

Well, the optimal gas consumption in a car is actually between 90 km/h and 120 km/h, so driving at 18 km/h you will use much more gas than driving at 100 km/h. So the analogy was indeed incorrect.
The statement would be correct, however, for much higher speeds, where the quadratic wind resistance forces you to use more gas, hence he went from 100 km/h to 200 mph in the example. Of course, you are correct he should've kept the same increase factor.

On a CPU, power is more or less linear with the clock frequency, while the speedup is less than linear (due to those wait states to access ram/flash) but very close, so in general using a higher clock frequency will consume about the same or slightly more total energy (this is energy, not power, as power is higher but for a shorter time). That's assuming nothing else changes (in this case the battery's internal resistance changes and this is no longer true).

[Claudio L.]

(08-09-2015 12:38 PM)Paul Dale Wrote:  In light of Cyrille's comment, there is possibly some room for improvement in the 34S firmware -- slowing the clock down during a long run seems sensible -- this is trading battery life for performance but not in a linear fashion.
- Pauli

If you take into account the cost of the time of the professional performing the long calculation, you will increase battery life, but increase the total cost of operating the calculator, not to mention the user's perception of a "slow" machine.
So using full speed is more economical in the end, as batteries are cheaper than the salary of a professional.
I wouldn't slow it down.

[cyrille de brébisson]

Hello,

whoa, I had no idea that this chat would spark that much debate... so let me try to clarify/cleanup a couple of things:

- The Atmel chip used in the 30b IS more energy efficient at lower clock speeds (ie, uses less energy to perform a calculation), for 2 main reasons:
- The clock can be generated using a very simple oscillator (think 2 not cells and a cap/resistance circuit which uses virtually no power), while the high speed is generated through a PLL (Phase Locked Loop) which is very power intensive (a non negligible fraction of a mA if my memory serves me well).
- The flash is not able to deliver data at the high CPU speed, so there is a 1 cycle delay on memory accesses. This means that it take more CPU cycles to execute a complex program at high speed than at low speed (ie, CPU cycles are wasted).

- replace the "car analogy" by "a non non hydrodynamic sold being propelled by an ideal engine through a fluid". In this case, moving it from point A to point B will take more energy at higher speed as the friction with the fluid increases.

Anyhow, the whole reason for the slow down is the fact that the battery does NOT like the long, high drain (they can heat up bad, especially if there is only 1 battery in the device), and that HP does state on the datasheet that the battery does last x months (I do not remember the exact number, under normal circumstances) and that HP needed to do what was necessary to make that happen. Plus, it's more ecological :-)

Cyrille

[Paul Dale]

(08-09-2015 02:47 PM)Claudio L. Wrote:  So using full speed is more economical in the end, as batteries are cheaper than the salary of a professional.

You didn't consider the confusion when the 34S resets during a computation as the battery gets low. We've had several people here wonder why it did this when the low battery indicator wasn't lit. To me, this trumps the battery life and performance -- the calculator needs to work first and foremost.


- Pauli

[Paul Dale]

Cyrille,

Do you have any numbers to quantify the effects of these things or any further details? After looking at the CPU's data sheet, it isn't clear that reducing saving a wait state is going to make a huge difference -- the flash has two sixteen byte read buffers which reduce accesses

I'm suspecting our slow mode ought to run a little slower to avoid the wait state on flash access (which we do a lot of). I'm not sure if slowing down to the R/C clock is viable or not.


Pauli

[Claudio L.]

(08-11-2015 05:27 AM)Paul Dale Wrote:  You didn't consider the confusion when the 34S resets during a computation as the battery gets low. We've had several people here wonder why it did this when the low battery indicator wasn't lit. To me, this trumps the battery life and performance -- the calculator needs to work first and foremost.


- Pauli

That's a good point. Nothing wrecks the nerves of a good professional like a reset after 20 minutes of calculations.

[Katie Wasserman]

(08-11-2015 01:23 PM)Claudio L. Wrote:  

(08-11-2015 05:27 AM)Paul Dale Wrote:  You didn't consider the confusion when the 34S resets during a computation as the battery gets low. We've had several people here wonder why it did this when the low battery indicator wasn't lit. To me, this trumps the battery life and performance -- the calculator needs to work first and foremost.

That's a good point. Nothing wrecks the nerves of a good professional like a reset after 20 minutes of calculations.

There's no fix for this problem other than running the calculator at a very slow speed all the time. The power supply design -- 2 CR2032 cells in parallel -- is about as bad as can be. All of HP's ATMEL chip-based calculators have the same problem, you can't measure the voltage nor power the calculator on one cell at a time. This is a fundamental flaw that requires a power supply redesign. HP used to know how to do this correctly, the HP95/100/200LX, for example, got this right!

[cyrille de brébisson]

Hello,

About efficient CPU speed.

I do not have the data on hand, but out of the top of my head, setting the flash to 1 wait state did have a measurable (small) effect. I did definitely run the Atmel devices at a low speed that allowed the 0 wait state and it did indeed help...

If the 30b was to run at full speed continuously with slightly weak battery, it would reboot/cause a low power reboot. which is why this 'feature' was implemented.
Now, this only happen in real life when running long user programs as pretty much none of the user functions will ever take that long (a complex IRR might do it, but that is about it).

Cyrille

[Marcus von Cube]

I might be able to add to the confusion.

The RC oscillator runs at 2 MHz, not 4 MHz. When idling, the 34S divides this by 64 to get roughly 32 KHz (the slow clock didn't work as expected so I chose to scale down the RC clock instead).

SLOW mode runs at approximately 20 MHz, FAST mode at approximately 37 MHz. Wait states (2 of them) are only set for the fast clock, together with a core voltage of 1.8V, instead of 1.55V at zero wait states when running at 20 MHz speed or slower. The frequencies mentioned here are accurate for a crystal equipped device only.

To manage power, the 34S does not step down the CPU speed but steps it up in a controlled manner. When entering digits 2 MHz is enough (unless some of the recent UI enhancements are activated which override this setting to get better responsiveness) . When a calculation starts, the speed is increased to 20 MHz after a short threshold (below one second). If the calculation takes longer, the speed is set to the maximum of 37 MHz. If the supply voltage is 2.5V or less, the maximum frequency is always limited to 20 MHz.

A device as complex as the 34S with a software that is mostly optimized for space, not speed, does not run very well at just 2 MHz. We might add a 10 MHz option but not less. If you want to play with the speed options look for set_speed in main.c and throughout the code.

[Csaba Tizedes]

(08-12-2015 04:55 PM)Marcus von Cube Wrote:  The RC oscillator runs...

OK, all of above posts are really interesting, but only one thing is missing: give me a number for 30b: from 100% to what percentage reduced the program running speed after 1 sec?! Thnx!

Csaba