[KERNEL][CM11.0/Omni/CM10.x]Boeffla-Kernel[v2.4 Beta6][24.09.2014]

[Lord Boeffla]

Ehrlich gesagt lädt das Handy gerade mit meinem LG nexus Ladegerät. Aber es war vor dem flashen und vor dem rom wechsel nicht so.

Welche ignore Punkte und was bewirkt das?

Was ist mit neu aufsetzen, würde das was bringen?

Was die Punk bringt steht genauestens in der Doku.

Neu aufsetzen bringt nichts, dadurch wird das Ladegerät nicht besser.

Es ist einfach so. Glaube hunderten von Leuten + Du findest das Thema überall über die Threads verteilt.

Andi

 

[gordon-1979]

Ich habe das Ladegerät vom Motorola, das bringt wenigstens stabile 1.0 Ampere raus, das Samsung schaft höchstens die 0.8 Ampere.

 

[Magnum1824]

So bin nun auch auf CyanogenMod 11 temasek's V9 umgestiegen, mit deinem Kernel-CM-2.1-beta1-cm11.0-r3p2 läut alles supi.
Danke Andi für deine hervorragende Arbeit und noch eine gute Zeit in Birmingham.

 

[Lord Boeffla]

Magnum, prima.

Und trotzdem werde ich noch heute (wenn ich es von hier aus schaffe) eine Version beta1a bringen welche noch zwei Bugs gefixt hat.

Konnte es mir gestern Nacht im Hotelzimmer nicht verkneifen das mal zu fixen.

Viele Grüße
Andi

 

[Magnum1824]

Lol Andi, du kannst es wohl nicht lassen , aber super werde dann mal testen und dir dann ein Feedback geben.

 

[crunkyy]

Noch mal um das Akku Problem auf zu greifen.

Ich kann das Problem nicht so einfach auf das angeblich schlechte Akkugerät abwälzen, ich lade immer mit dem selben Ding mein nexus 4 Problemlos. Das s3 hat lade Probleme seit den beiden Flash Vorgängen cm 10.2 und boeffla Kernel.

Es muss doch einen anderen Grund geben. Bin offen für alle Tipps.

 

[peterle111]

Der Grund kann auch abgenutzte oder verbogene Kontakte in der Micro USB Buchse des s3 sein. Zumindest eine Erklärung warum es beim nexus lädt und beim s3 nicht.

Rom oder kernel technische Probleme dieser Art kann ich von meiner Seite her ausschließen.

Grüße peterle

 

[crunkyy]

Oh stimmt das mit den abgenutzten oder verbogenen Kontakten kann sein. Sieht man das mit dem bloßen Auge?

 

[Grabbo]

Habe das gleich Problem beim meinem sohnemann. Mit 4.3.1 lädt das S3 sehr lange und mit der 4.3 ohne Probleme. Bei meinem s3 ist das egal welche Version lädt immer konstant.

 

[gordon-1979]

@crunkyy Flashe einfach die CM10.2 ROM neu und nimm eine Aktuelle gleich, dabei Factory Reset nicht vergessen.

Rom oder kernel technische Probleme dieser Art kann ich von meiner Seite her ausschließen.
Grüße peterle

Wenn in der ROM der Ladestrom zu wenig eingestellt ist, lädt es auch extrem langsam. Daher sollte mach zur Sicherheit verschiedene ROMs auch mal durch testen.

 

[Mugello07]

Hab da mal eine kurze Frage,
welcher Governor inkl. Governor Profil, ist denn unter dem Aspekt des Batterie sparen geeigneter, zzmove @yank battery oder pegasusq @ boeffla battery saving?

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

 

[SmokeDroid]

Ich nutze seit tagen pegasusqplus battery, da hält der Akku gut und 3D spiele ruckeln nicht

 

[Mugello07]

Was ist denn der unterschied zwischen Pegasus und pegasusqplus? Konnte auf der boeffla Website nicht finden

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

 

[SmokeDroid]

Kein plan aber qpus battery läuft gut, pegasusq zieht mmn mehr Akku bzw mit boeffla Akku ruckeln spiele etwas, zumindest kam mir das so vor...
Finde leider auch keine infos zur plus Version, aber läuft gut.
Meine Freundin hat nach 24h noch 30% akku
Mein Telefon zählt eh nicht für dir Statistik weil ich viel tekken und Simpsons spiele ^^

 

[nominator2204]

Hab jetzt auch die temasek v9 mit dem aktuellen boeffla kernel am laufen.
Einfach ein Traum wie das s3 rennt. Alles was Andy zur Verfügung stellt rennt einfach nur wie sau

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

 

[buchholz]

hier die Erklärung zum Pegasusqplus, hatte mir Andi selbst vor ein paar tagen gegeben




New PegasusQ logic:

- Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.

- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.

- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.

- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.

- Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):

lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.

- Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.

- Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.

- Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.

- Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.

- Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.

- Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.

- Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.

 

[nominator2204]

Kein plan aber qpus battery läuft gut, pegasusq zieht mmn mehr Akku bzw mit boeffla Akku ruckeln spiele etwas, zumindest kam mir das so vor...
Finde leider auch keine infos zur plus Version, aber läuft gut.
Meine Freundin hat nach 24h noch 30% akku
Mein Telefon zählt eh nicht für dir Statistik weil ich viel tekken und Simpsons spiele ^^

Läuft Pegasus plus bei dir akkuschonender Als battery yank extrem?

Gesendet von meinem GT-I9300 mit der Android-Hilfe.de App

 

[SmokeDroid]

Keine ahnung , müsste ich testen, aber bin da vorsichtig, KB das tekken im online match ruckelt
Aber bei meiner Frau läuft es trotz cm wie Samsung stock

 

[peterle111]

Eigentlich hat der Pegasusqplus nur das angepackt was schon lange beim zzmoove läuft. Trotzdem hat der zzmoove immer noch bessere Akkuleistung bei bester CPU Nutzung. Da hat zanezam und yank schon was feines konzipiert.

Grüße peterle

 

[NoobAnd]

Welche Kombi sollte man dann deiner Meinung nach nehmen?