Jump to content


Photo

Testing: Custom kernel with cpu frequency scaling/overclock enabled


  • Please log in to reply
42 replies to this topic

#1 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 16 September 2010 - 04:50 PM

(EDIT: The original version of this post had the available clock speeds @ 66-533Mhz, but this was miscalculated due to an error in VIA's source release. Actual speeds are now shown below. Some posts may refer to the old/wrong speed scale.)I've enabled the CPU frequency scaling features that were partially implemented by Wondermedia, but never turned on. When running Android so far, the actual CPU frequency appears to always be 350Mhz. With this kernel it can be set as high as 387Mhz, and as low as 50Mhz.The new kernel adds sysfs interface /sys/devices/system/cpu/cpu0/cpufreq and should support the Android app SetCPU, although I haven't actually tested that app.It is possible to set "ondemand" scaling where the kernel automatically speeds up and slows down depending on load, although this can make the tablet a bit unresponsive when idle. By default the new kernel will just boot at 350Mhz, same as old. So you won't see any changes unless you make them.Files for testing are hereIMPORTANT: No warranty, no guarantees, for testing only. This kernel may be unstable, and it could even possibly damage your device. Use at own risk, etc.I've also posted a small console program, wmt_getspeed, which interrogates the hardware registers on a device to report the CPU speed. It also does a very lo-fi microbenchmark which appears to roughly scale with the CPU speed. The way to run it and get a vaguely correct benchmark (from a root console) is 'nice -n -19 ./wmt_getspeed' . Better to run it from Debian than Android as well, Debian has many fewer background processes running to interfere. This program is how I determined the stock kernel multiplier.The formula for calculating Mhz originally came from VIA's source but was wrong, has now been corrected.I also posted an alternative scriptcmd which will boot the loaded version of Android from a different kernel on the SD card. This lets you test out different kernels without reflashing the entire device (big time saver for me!)Finally(!), kernel source is pushed to github so please build your own or hack on it some more.Please post experiences/results! If running Android-based benchmarks, please remember that results will vary based on what else is running in your system at the time.Todo:* Implement newer cpufreq table interface in the kernel (currently, SetCPU needs a "SetCPU.txt" file - posted - to get full functionality.")* Clean up the calculations for determining optimum CPU & AHB dividers.* Look into supporting kernel 'cpuidle' support for better idle/standby power savings.

#2 mammlouk

mammlouk

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 291 posts

Posted 17 September 2010 - 12:14 AM

This is great news! It sounds like some great progress is being made. Is the code for the video driver in the got repository? It seems that performance is horrible in portrait vs landscape. Any chance for improvements there?Sent from my Droid using Tapatalk

#3 lefeudedieu

lefeudedieu

    Advanced Member

  • Hero Member
  • PipPipPip
  • 664 posts
  • LocationToulouse

Posted 17 September 2010 - 02:23 AM

HelloI tested this kernel, thank you to the author.A quick resumé with Linpack and CpuBenchmark:CpuBenchmark 300/533Mhz:Posted ImagePosted ImageThere is an increase in performance benchmark.The battery does not seem to heat up more, it is necessary to check the autonomy.Thank you again has projectgus.EDIT :I think if you can do that we can increase performance with the JitHack, I tried to integrate but it hangs at the first logo.G1 on the benchmark nearly doubles!Just-in-time compilation - Wikipedia, the free encyclopediahttp://forum.xda-dev...ad.php?t=637419http://forum.xda-dev...ad.php?t=641473This would be a real advance in performance.If you can see ?

#4 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 18 September 2010 - 03:09 AM

(EDIT: this post now has correct Mhz values in it!)lefeudedieu, thanks for rolling this into the firmware so quickly. I've seen the "dusted donut" JIT tricks in the past, I haven't really looked into them... I've heard reports of instability and the whole thing just seems like an evil hack. Keener to devote my time to trying to get 2.2 to work properly, even though that's a much harder task.Anyhow, I went ahead and made some power consumption measurements.SummaryThe good news is running at 387Mhz does not seem to consume much more than at 350.The bad news is that running slow doesn't save a whole lot of power. Standby at 50Mhz draws just 50mA less current than standby at 387Mhz. To get any more power savings, will need to add 'cpuidle' CPU idle state support to the kernel.My results show that dimming the screen and (espeically) turning WiFi off are the key ways to save power. This follows on from the good investigations done by tron33.MethodI inserted my multimeter into the circuit between the battery and the main board of my long-suffering M001. So I'm directly measuring current in/out of the battery. Current draw will directly correlate with battery life.All my interaction was done via the serial console, not the UI, in order to keep the Android CPU usage as predictable as possible.When measuring "Idle consumption", I confirmed idle CPU was over 98%.To load the CPU I ran a micro-benchmark which loaded it directly up to 100%. Maybe other kinds of heavy I/O (network, flash, SD) might also impact the power usage differently, but I didn't test them.ResultsIdle with the screen off:387Mhz 320-330mA350Mhz 320mA275Mhz 310-320mA175Mhz 300mA75Mhz 290mA50Mhz 280mAScreen off with CPU @ 100%:387Mhz 360mA350Mhz 350mA275Mhz 340mA175Mhz 310mA75Mhz 290-300mA50Mhz 290mAScreen on/off @ 387Mhz, idle, showing Android lock screen100% brightness 500mA75% brightness 470mA50% brightness 420mA25% brightness 380mA0% brightness 320mAUSB power on/off @ 387Mhz, screen asleep.Wifi on but not associated, 320-330mAWifi powered down 200-210mAI couldn't get the new firmware to associate with my wifi access point, so I didn't do any other Wifi measurements. :)

#5 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 18 September 2010 - 09:46 PM

EDIT: Fixed the clock speeds in this post, too!I decided to run some benchmarks in Android (until now I'd been benchmarking in Debian where I had more control over what was running in my system.)I booted my M001 (Slatedroid Mercury Beta + custom kernel) and waited for the initial CPU usage to die down (this takes several minutes.) I disabled the screen off timeout. Then I used SetCPU to set the CPU at 300, 350 & 387Mhz in turn. For each run, I ran the Long Bench and Native Bench options in SetCPU 4 times each. Then I repeated the entire process, so I had 8 samples of each, for each clock speed.Anyway, raw results and very basis analysis is here.The deviation between individual samples in the Java-based Long Bench was very large. The improvements from any clock speed increase were often swallowed by the vagiaries of the Dalvik VM. Probably factors like memory access are more important for interpreted Java applications. However, if you accept that higher benchmark times are always the result of other processes competing for time then the lowest recorded benchmarks for each clock speed (ie the one with the least interruptions) still shows a clear improvement.The native benchmark, which bypasses the VM, shows a much clearer picture of improvement. The CPU itself is definitely running faster when set at 387Mhz than it is at 350Mhz.

#6 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 12:47 AM

Grr. So VIA's source code has the base clock speed at 33Mhz, but according to the datasheet it's actually 25Mhz. I didn't think to check.So when I stated stock speed 466Mhz, available range 66-533Mhz it was actually stock speed 350Mhz (as previously guessed), available range 50-387Mhz. Due to the different base speed.New source, kernel & setcpu files have been posted, sorry for the mixup. I have no idea why VIA released kernel source based around the wrong base frequency, possibly that file was for a different device?

#7 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 12:56 AM

I did a couple more experiments today, as well:- Even though it's possible to set the PLL multiplier above 31 (for 387Mhz), the system seems to lock up nearly instantly. So 387 is probably as good as it gets.- I've been playing with the DDR RAM frequency a bit. It doesn't appear to improve performance by increasing it, but reducing it at standby seems to save about 10-20mA of running current. However, it also introduces an annoying flicker in the screen (LCD controller reads its values from framebuffer in RAM) so it's probably no use rolling it into cpufreq.

#8 metal03326

metal03326

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 82 posts

Posted 19 September 2010 - 01:02 AM

Is there a way to make RAM frequency lower when the display is off and restore it's previous value when display is on? This can save some battery B)

#9 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 01:14 AM

Is there a way to make RAM frequency lower when the display is off and restore it's previous value when display is on? This can save some battery B)

Maybe. I think the long term best way to go is to try and implement some of the dedicated standby modes. They're documented in the datasheet, just need to work out how to integrate them into the kernel. Then Android can call 'Hibernate', which should use significantly less power.

#10 lefeudedieu

lefeudedieu

    Advanced Member

  • Hero Member
  • PipPipPip
  • 664 posts
  • LocationToulouse

Posted 19 September 2010 - 01:26 AM

Hello projectgus,I have a 2.1 SuperEclair if you want that has the same kernel 2.6.29 that the M001.Little-be be easier to work than 2.2 FroYo?Tell me if you want the link.I do not agree on JitHack is very stable on 1.6 and 2.1 is that it is useless for froyo.Really it would be nice if you do a test, I have the files if you need?Thank you for your work and good luck.

#11 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 01:33 AM

I have a 2.1 SuperEclair if you want that has the same kernel 2.6.29 that the M001.

Thanks lefeudedieu' date=' but I'm guessing it's not actually a kernel for the Wondermedia WM8505, right? We need to use a kernel with the correct hardware-specific support, which is why we are currently working from VIA's source release (there is also a compatible kernel being written from scratch, but it's a long way off being ready to boot Android.)

#12 3l1k

3l1k

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 68 posts

Posted 19 September 2010 - 11:16 AM

written from scratch[/url], but it's a long way off being ready to boot Android.)

Hi! I'm frequently read your google group and alexey charkov gittorius site. I have a questions for you: how about 2.6.35 kernel ? do you solve problems with GE/graphics driver ? are the kernel boot ? really interesting :(

#13 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 06:10 PM

Hi! I'm frequently read your google group and alexey charkov gittorius site. I have a questions for you: how about 2.6.35 kernel ? do you solve problems with GE/graphics driver ? are the kernel boot ? really interesting :)

Alexey's kernel is the "good" one, in that it has clean code and it's well implemented. However, it's still missing a lot of drivers - for instance, there's not yet support for flash, USB, audio, touchscreen. The graphics support on WM8505 has been implemented, but it doesn't yet support the correct video modes for Android. So it's coming along, but it's a long way off at the moment.So the kernel boots, it just won't boot Android or any useful Linux distribution. Yet. But those guys are working hard, and I'm sure it will.The reason why I found the cpufreq support in the first place was that I was digging through VIA's source, looking for components that could be cleaned up and merged into Alexey's tree.

#14 thebluecrab

thebluecrab

    Member

  • Jr. Member
  • PipPip
  • 16 posts

Posted 19 September 2010 - 07:58 PM

[quote name='projectgus;60520]Maybe. I think the long term best way to go is to try and implement some of the dedicated standby modes. They're documented in the datasheet' date=' just need to work out how to integrate them into the kernel. Then Android can call 'Hibernate', which should use significantly less power.[/QUOTE'] Could you post the datasheet?Thanks,TheBlueCrab.

#15 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 19 September 2010 - 10:30 PM

Could you post the datasheet?

sure :)

#16 HidePerso

HidePerso

    Advanced Member

  • Hero Member
  • PipPipPip
  • 409 posts

Posted 20 September 2010 - 06:07 AM

[quote name='thebluecrab;61020]Could you post the datasheet?Thanks' date='TheBlueCrab.[/QUOTE'] http://www.slatedroi...-datasheet.html

#17 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 20 September 2010 - 07:17 AM

I made some battery life measurements last night, and they look pretty good. By scaling the CPU back to 50Mhz while idle, it should be possible to get an extra 1 1/2 hours of standby out of my M001 - from 5h50m (stock) to 7h25m.Not too shabby, although a bit depressing when you consider an iPad can go nearly a month. But who's counting! :) At least it's a good incentive to get some actual suspend/hibernate functionality working.The full results are published here. Battery life estimates with the screen & the wifi on are lot less impressive, because those two components use most of the power. So my advice is to switch them off when you're not using them! At the same time, you're not going to notice any significant battery life loss if you run at 387Mhz compared to 350.MethodFor those who are interested, my method was to run a small script which logged the time every 15 seconds, then leave the tablet to run down with screen & wifi off. This set load average at 0.00 most of the time, drew a constant 210mA of current from the battery (in line with my measurements from the other day) and lasted 5h50m before it finally gave up the ghost. This gives a usable battery capacity of 1225mAh, not too shabby for a battery labelled as 1600mAh. Bear in mind some M001s (and others) have different battery models inside, so YMMV.Anyway, using the 1225mAh figure and the instantaneous power consumption measurements I took yesterday, I calculated estimates for all the other combinations of usage. They're just estimates, but they should be mostly accurate. Although there are other things that may factor in, like network I/O and heavy flash or SD card I/O.Hth.

#18 tipstir

tipstir

    Plagerist

  • Banned
  • PipPipPip
  • 1,115 posts

Posted 21 September 2010 - 12:54 AM

Very interesting info here. So the jest here that these CPU from VIA even though rated at 533MHz can't even reach that rate. Using SetCPU on the latest Rooted ROM for the Flytouch 1.9.1 first 350MHz, then 387MHz, but I was able to the bar to 500MHz for the max. But yet it wasn't able to lock in at the FREQ. I was able to play a MP4 video @ 720x480p full screen. Audio was alright until the video kicked in which the audio was out of sync with the video. This tool you use to benchmark the system seem state the CPU can reach 500MHz then can it be reach then?

#19 projectgus

projectgus

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 255 posts

Posted 21 September 2010 - 02:30 AM

No, all claims of 533Mhz or 600Mhz were seller exaggerations only. On the new (correct clock rates) kernel you won't be able to set above 387Mhz, I found that on my M001 any higher would lock up almost instantly, so I thought there was no point leaving support there. Possibly you have a 'setcpu.txt' file that specifies the old (wrong) frequencies, which is why it's letting you try higher values. I suggest downloading the latest setcpu.txt if this is the case.I don't think the extra 10% CPU clock will make more than a minor difference to video playback, either. :).

#20 Intri

Intri

    Advanced Member

  • Jr. Member
  • PipPipPip
  • 119 posts

Posted 21 September 2010 - 06:03 AM

latest setcpu.txt[/url] if this is the case.I don't think the extra 10% CPU clock will make more than a minor difference to video playback, either. :).

So, 387 MHz is a deadline above which there is a no go?