ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #00685
Re: Tethering and Overclocking?
Agreed Benjamin, the average user should not have this kind of CPU control. But the Android application called "Set CPU” keeps things simple enough that most people can operate the over / underclock without any risk of damage as it auto detects that maximum safe overclock. And the returning to idle is a little sketchy when listening to music, broswsing the web, and bouncing back and forth from a messaging client. On newer devices as of now that is easy. But on my Droid 2 the standard speed is 800 mhrz from stock. so overclocking to 1200 mhrz makes these tasks much smoother. It has never gotten hot on me at all. So why the manufacturer only sets it to 800 is beyond me. To encourage uninformed users to upgrade??? Lol
Anyway over clocking would mainly be to extend the usable life span as games and videos will require more speed after 2 to 3 years and now that we are spending upwards of 300 on these devices in contracts. We need to get as long a usable life as possible. I would rather overclock and burn up the CPU after 5 years but using it the whole time, than have a obsolete and unusablely slow device after only 2 or 3. Which would be the case with my Droid 2. The underclock to save battery is just a bonus until I either can afford a 60 dollar battery or a 300 dollar phone. Unemployment strains things.
So in closing, I feel that clock speed contol should not be a GUI default app. But should include a simple terminal control with great documentation so power users or app devs can easily take advantage of them.
God Bless you all, and sorry for the long reply. Lol
Dan
Benjamin Tegge <benjaminosm@xxxxxxxxxxxxxx> wrote:
>Hello Daniel,
>
>'Tethering' functionality should be provided in the network settings
>like
>on the current desktop interface, IIRC.
>
>IMHO I think the user shouldn't interfere with CPU scaling and other
>things
>like schedulers as the Franco kernel does on Android. Good defaults
>should
>cover these situations.
>
>Droid 2 sounds to me like it's over 3 years old, you should spend a few
>bucks on getting a replacement battery instead of fuzzing with
>frequencies.
>The Franco kernel already showcased how tricky it can get for only a
>few
>chip sets to get the different frequencies right. Giving the user
>control
>about these settings wasn't part of the default desktop and shouldn't
>be
>for the phone either. Also I recall that governors have been discussed
>on
>LKML a few years ago and the result was that the CPU should finish work
>as
>fast as possible to get back into idle state. All in all giving the
>user
>control in the GUI just gives more options to screw up a device. Savvy
>users always can do these tasks from the terminal and probably read the
>documentation.
>
>Regards, Benjamin
Follow ups
References