cpu mode

[ced]

I\'m currently writing an automatic cpu frequency adjustment software (to be used in conjunction with the overclocking kernel patch). So I can downclock/overclock the cpu based on the user load.

What do you consider the zaurus in idle/busy state?

 idle mode >= 80% cpu idle
 busy mode <= 50% cpu idle

I\'ve tried to get a feeling using the command \'top\' (refreshing rate 1s), here are my findings:
  - do nothing -> ~80% idle
  - open application -> < 40% idle
  - sharp media player running -> ~50% idle
  - chess Knights computing -> 0% idle
  - chess Knights waiting for user inputs -> ~70% idle

Any comment will be appreciated... :-)

Ced.

[lardman]

Sounds interesting. Presumably the points (or even a continuous function) you choose will depend on how much worse the power consumption is when overclocked? Or will you have two regimens, one for battery and one for mains power?

Presumably if less than 100% of the processor time is being used, then a given process hasn\'t run up against any particular speed issues and is just wanting for IO of some kind. Increasing the processor speed will reduce overall run time assuming that any IO can be completed quickly enough.

What about calculating the difference in processor useage between a 0% increase and 100% increase (do a quick average processor useage for each) and then using this to work out how much the processor speed needs to be increased to deliver the maximum throughput.

Just a thought,


Si

[ced]

I\'m not doing this software for power consumption.
I was thinking about if the zaurus doesn\'t use cpu power then the cpu don\'t need to be overclock (it\'ll reduce heating, life, battery, etc).

I don\'t really get your last paragraph... :-(  my brain need a bit of math practice... :-)

[lardman]

I\'m not sure if it makes sense. What I was thinking is to try and find a quick method to do the following easy (hopefully) to understand process, otherwise the state will have changed too much - that is:

- Stick the overclocking up to its maximum, look at the processor useage. If it is at 100% then leave it there as all of the CPU cycles are being used. If it\'s not then continue...

- Start looping, reducing the overclocking rate as you go and each time checking to see what the cpu usage is. My assumption was that you could keep pegging the processor speed back until the processor is running at 100% which would mean that the IO is being performed as quickly as it can be, and at a minimum of processor power consumption.

However, this is not actually true (it would be for a processor which continued to consume power as if it were running even when not being used). Now that I\'ve thought about it, there\'s a trade off between the amount of time running and at what overclocking speed and the amount of time the processor is stopped (I presume this sticks it into low power mode?).

This is some kind of constrained optimisation problem, and knowing the power consumption of various processor overclocking speeds as well as the stopped value I suppose some sort of scheme could be worked out.

Hope that makes sense,


Si

[Greg2]

This does indeed sound interesting, but I will let all that math up to you. I would just like to be able to manually control the overclocking and I\'m sure that others would like to try the special kernel if they could control it also.

Greg

[lardman]

I just had a quick google and found some interesting links and other programmes which are used to scale CPU frequency (for those laptops with mobile processors, etc.), but could presumably apply equally well to this. I\'m sure you\'ve already seen all of this, but just for everyone else\'s interest:

http://mrl.nyu.edu/~danielk/linux/cpufreq.html

and from there:

http://www.deater.net/john/powernowd.html

This page also has lots of papers about different algorithms, etc. Might be worth a look: http://www.eecg.toronto.edu/~tamda/csc2228/



Si

[Stephen]

A couple of thoughts on this:

As lardman suggested, you should determine  a target cpu usage and attempt to keep the usage at or near this usage.  I propose you make this target usage user specified(Say, anywhere from 30% to 80%).


• One potential problem with too high or too low of a range is that you\'d either consistently underclock or overclock the cpu(Using Lardman\'s 100% example there would be no easy way to know when you should ramp up the clock rate and so the zaurus would gradualy slow down)
• CPU usage tends not to be continuous but rather spikes infrequently.  It would be nice if the program could ramp up the clock rate quickly.
please observe this psuedo-code for what I beleive would be a decent approach:

Code: [Select]

clk_monitor_and_adjust(cpu_usage, target_usage)

{

   if (cpu_usage < (target_usage - BUF))        // we\'re clocked to high

      change_clock(cpu_usage - target_usage);   // change clock speed down(negative)

   else if (cpu_usage > (target_usage + BUF))   // we\'re under clocked

      change_clock(cpu_usage - target_usage);   // change the clockspeed up(positive)

}



change_clock(scale)

{

   if ( (scale > 0) && (Current_Clock_Rate < MAX_CLOCK_RATE) )

   {

      // scale up the clock rate according to scale never exceeding MAX...

      //  and perhaps according to the history of scale

   } else if ( (scale < 0) && (Current_Clock_Rate > MIN_CLOCK_RATE) )

   {

      // scale down the clock rate according to scale never dropping below MIN...

      //  and perhaps according to the history of scale

   }

}

So what do you think?

[lardman]

One potential problem with too high or too low of a range is that you\'d either consistently underclock or overclock the cpu(Using Lardman\'s 100% example there would be no easy way to know when you should ramp up the clock rate and so the zaurus would gradualy slow down) 

I was thinking that the analysis would be continuous (though I didn\'t write it), so it would then keep looking. Especially when at 100%, try moving the CPU speed up a bit and see whether the CPU usage drops at all, etc.

CPU usage tends not to be continuous but rather spikes infrequently. It would be nice if the program could ramp up the clock rate quickly. 

Yes, that\'s the problem with my \'algorithm\', though I also posted a page with a load of papers which presumably deal with this. I\'ll take a look at the this evening and post what I find later/tomorrow.

As lardman suggested, you should determine a target cpu usage and attempt to keep the usage at or near this usage. I propose you make this target usage user specified(Say, anywhere from 30% to 80%). 

I still wonder about how to set this amount. For example if a task could complete in 10sec @100% cpu usage and @150% clock speed, would this be better than 20sec @75% cpu usage @100% clock speed. It all depends on how you weight the conflicting factors which you\'re trying to optimise (power consumption, processing time, others?). Anyway in this case, assuming you\'re just optimising power consumption and trying to make the beast as fast as possible, it would be reasonably easy to decide which is better knowing the power consumption for 0%, 100% and 150% cpu speed.


Simon

[tumnus]

ced posted a link to an overclock GUI in his howto: http://www.piro.hopto.org/~piro/zaurus/qcl...ge_0.1a_arm.ipk

I haven\'t noticed any real increase in battery consumption or heat generation (the front light seems to generate the most heat anyway) and the basic XScale idling probably already provides the most savings. But hey, there\'s always room for improvement

[lardman]

But hey, there\'s always room for improvement 

Exactly...

From one of those papers here are the percentages (for an iPAQ idling):

Frontlight 30%
LCD 8%
SDRAM 11%
Audio 22%
IrDa 14%
RS232 3%
Other 12% (this is CPU, flash mem, touch screen, etc.)

So obviously turning off the back/frontlight makes a huge difference (as does turning the whole LCD display off). Is it possible to turn the audio chip off?

In any case, as you say, scaling the CPU speed is a worthwhile endevour IMHO (esp if it moves over to the 5500 eventually ... ;-).

I\'m looking at those papers, but from my preliminary scan there doesn\'t seem to be anything ground breaking, I\'ll keep you informed.


Si

[Anonymous]

Thanks a lot for the links, the algorithms and the speudo code.

I\'m on a course all next week so don\'t expect something to be done very quickly... :-)

Regards,
Ced.

[lardman]

Right, I\'ve spent the last hour reading the papers I pointed out above. I\'m sorry about the length of this post, but it might be of interest to some of you out there (who can\'t be bothered to read the papers).

These are my findings:

Useful keywords (for those who might like to google a bit):
Dynamic Voltage Scaling (DVS)
Voltage Scheduler

This field appears to have been running for ages, but I\'d not even thought about it until I chanced upon this thread a few days ago. In fact the main aims of the field are to do with mobile processors which allow scaling (which I presume the Xscale does, I think the SA1110 does). Overclocking simply increases the speed range for us, so there\'s no real difference. The aims and goals are identical - save power, get job done within required time, remain interactive, etc.

Basically there are two bits to DVS - Predicting what the workload will be and Working out what to set the speed to. Workload = (total_cycles - idle_time)/total_cycles @ max speed, the goal is to make idle_time=0 so that the workload is always 100% and the speed is as low as possible.

Needless to say there are lots of methods for both. I note that most/all of these algorithms don\'t take IO into account. Should IO occur they effectively recalculate their deadline times making them shorter, but they don\'t seem to use any sort of profiling of the IO history (as they do with the idle time for example) to take this into account.

prediction:

PAST - assume that the next workload will be the same as the last.

PEAK - predicts that a rising run rate (run cycles/idle cycles) will fall symetrically and that a falling run rate will continue to fall. They use hysteresis for the speed-setting part to ensure that the task can actually keep running.

AGED/AVGn - average past workloads, give higher weighting to the more recent (lots of variations - various moving averages, different weighting schemes, different numbers of samples, etc.)

FUTURE - look into the task queue and try to predict what these tasks will need based on past experience of similar ones.


Speed-setting:

Weiser-style - If the workload prediction is high (70%), increase the speed by 20% of the maximum speed. If the workload prediction is low (50%), use the Chan-style technique below.

Chan-style - Set the speed for the upcoming interval just high enough to complete the predicted work. In other words, multiply the maximum speed by the workload to get the speed.


My comments and questions:

My I note that the SA1100 can scale its voltage from 59MHz -] 206MHz (ignoring overclocking) in 10 steps, to perform power saving. Is this behaviour implemented at all on the 5000D/5500 (different processor I know, but pretty much the same I assume)? Do the overclocking tools allow this (ie. is it performed by the same method)?

One method I saw ignored niced processes completely for the calculations, which makes sense - if a process has been niced it presumably doesn\'t have a time limit for its execution.

One of the papers had an interesting idea of having 3 layers of software doing the speed changing:

level 1 waited for user input and could override the lower levels to ensure that the user experience remained satisfactory. I guess there are issues here with response times, etc. But basically I think the goal is to jump straight to 100% when user interaction had been detected, then drop back to the normal scheme once it has stopped.

Level 2 was an idea (unimplemented) for communications with applications, so that apps could tell the system what kind of deadlines/execution times they required (reducing the need for the prediction bits above). I also think that an IO profile could be provided here. Needless to say this would be extra effort for the programmer, but I\'m sure it could be automated to a degree. Just how useful it would be is open to debate, but it might help.

Level 3 is what I\'ve been describing above, predicing future needs and scaling the CPU speed appropriately.


A fair few of these papers were about the iPAQ (which IMO is similar enough to the Z to be worthy of comparison). From one paper/presentation (same as the one I got the percentages from in a previous post):

With all the unused chips turned off and the frontlight off, an iPAQ running Linux consumes 1.9 times as much power of the same machine running WinCE. Not ideal.

When LCD is on, most other chips are off and CPU is idle,
- Linux iPAQ consumes
470mW with linux kernel (2.4.x I think)
280mW with SDRAM power down mode
238mW with SDRAM power down mode and 30Hz screen refresh rate
172mW with SDRAM power down mode and CPU speed 56MHz (lowest possible)

- WinCE iPAQ consumes
248mW

= Note
Consumes 460mW more power if the front light is on
Linux can consume as low as 98mW if it also turns off LCD

I thought it was interesting anyway. Now to start downloading the kernel source and have a go.


Si

[ced]

I\'ve implemented the AVGn algo due to the best result in performance.

I\'ve noticed when you change the frequency then the screen flicker and produced vertical white line.

I don\'t think I can do a nice automatic adjustement software due to these screen issues... :-(

[lardman]

I\'ve noticed when you change the frequency then the screen flicker and produced vertical white line.  

Does this happen all the time? What about with one of the user land tools? Any ideas as to the cause?


Si

[ced]

yep every time...

apparently form Intel, you have to disable the LCD before changing the cpu frequency...

user land tools??