[KERNEL(Nougat)][ROM]Kylo Kernel/UBERSTOCK

Search This thread
By:
Advanced…
Lawlrus

Lawlrus

Senior Member
Nov 20, 2013
10,687
6,599
@sage of six paths

Try gsam or maybe even accubatery off the play store, give it permissions to monitor apps if you have to.

Gsam always worked out pretty well for me, I just started looking at accubattery so I'm not sure how well it does.

Biggest thing is checking to see what apps if any are keeping your device from entering deep sleep, and creating wake locks

Edit: forgot the name of it because I haven't had to monitor this **** for a long time, but better battery stats was always my go to. Think you can just search via google and get the apk off of XDA.
 
Last edited:
  • Like
Reactions: sage of six paths
sage of six paths

sage of six paths

Senior Member
Oct 15, 2014
437
67
Zenica
Lawlrus said:
@sage of six paths

Try gsam or maybe even accubatery off the play store, give it permissions to monitor apps if you have to.

Gsam always worked out pretty well for me, I just started looking at accubattery so I'm not sure how well it does.

Biggest thing is checking to see what apps if any are keeping your device from entering deep sleep, and creating wake locks

Edit: forgot the name of it because I haven't had to monitor this **** for a long time, but better battery stats was always my go to. Think you can just search via google and get the apk off of XDA.
Click to expand...
Click to collapse

There isn't any need for that. My biggest culprits i guess were gps and i've dozed that, and the facebook and messenger and i'm using light versions of those. So if the battery usage stays like this i did it. I have the accubattery pro but i dont use it anymore. It didnt really tell me anything new. Facebook and Instagram were draining the battery the most. I've used it mainly for checking the health of the battery. I still recommend using amplify and doze for gps, i think u will get the best results from that. As soon as there is any official xposed for pie, i'm moving since i really like pie a lot more than oreo. We can move to dm if necessary so we dont spam the topic.
 
Last edited:
Sheetzie03

Sheetzie03

Senior Member
Feb 23, 2011
3,612
1,462
Pennsylvania
Google Pixel 7
Google Pixel 7 Pro
sage of six paths said:
There isn't any need for that. My biggest culprits i guess were gps and i've dozed that, and the facebook and messenger and i'm using light versions of those. So if the battery usage stays like this i did it. I have the accubattery pro but i dont use it anymore. It didnt really tell me anything new. Facebook and Instagram were draining the battery the most. I've used it mainly for checking the health of the battery. I still recommend using amplify and doze for gps, i think u will get the best results from that. As soon as there is any official xposed for pie, i'm moving since i really like pie a lot more than oreo. We can move to dm if necessary so we dont spam the topic.
Click to expand...
Click to collapse

Definitely Can't hurt in my opinion, that's for sure.

I hear you with Facebook. Rather than using the lite version, I stopped using it all together a few years back. Lol It's an awfully optimized application, not to mention so much of its substance is useless garbage lol But yeah if you use it to speak with family and friends, I understand you have to use it.

And then w/ Accubattery, a little while back everyone was talking about this And they basically put their trust in it. But more and more I'd see that what Accubattery was reporting, mainly regarding the health of some ones battery, simply wasn't Accurate. Many times it would say a battery is fine when it absolutely wasn't and needed replaced. And Vice versa. So I stopped trusting/using the app. Maybe others have also caught on because I haven't heard nearly as much as I did about it like a year ago.

Later Mate
 
M

mojorisin7178

Senior Member
Jun 26, 2011
905
136
44
Saint James
Google Pixel XL
Google Pixel 3a XL
Lawlrus said:
You should be more worried about random reboots on pie with a custom kernel than battery life, if you do any reading at all in pie threads you would see its still currently unstable custom kernel wise.

If you want the best battery life for this device stay on 8.1. Future versions of android on this device will NEVER be as good, or have better battery life than the OS versions that were actually optimized for the device by google


That's how outdated devices go.
Click to expand...
Click to collapse
My wife's Galaxy s5 got los 15 and battery life was excellent. Better than stock marshmallow. And my note 2 was the same thing much better battery life. But other devices I have had did lose battery life due to custom updates. So I guess it depends.
 
Lawlrus

Lawlrus

Senior Member
Nov 20, 2013
10,687
6,599
mojorisin7178 said:
My wife's Galaxy s5 got los 15 and battery life was excellent. Better than stock marshmallow. And my note 2 was the same thing much better battery life. But other devices I have had did lose battery life due to custom updates. So I guess it depends.
Click to expand...
Click to collapse

You're talking about going from some company's bloated ass version of android to a custom pure aosp? I mean that makes perfect sense, and shows why in stopped supporting such devices after my lg g2.

But if you're talking about pure aosp, to pure asop, then more tikes than not, you will start getting reduced performance in an outdated device.

I've been in the custom android scene since the OG droid RAZR battle tank that was a six lb piece of steel lol. Sometimes there's non difference, sometimes its better, but the vast majority of the time its bad. People want their devices tonplay full feature vidya games now, that wasn't the case three years ago.
 
You must log in or register to reply here.

Similar threads

flar2
[KERNEL] ElementalX-N6P
Replies
9K
Views
1M
nesan95
nesan95
franciscofranco
[KERNEL][N6P] FrancoKernel ⚡️- r77 - 7th December - Oreo & Pie
Replies
7K
Views
1M
Lughnasadh
Lughnasadh
ak
  • Locked
[KERNEL][07/04][AOSP/CM/NH][F2FS][EAS][3.10.101][UBER5.3] ☆ AK ☆ [v. 063]
Replies
2K
Views
278K
KennyG123
KennyG123
smac0628
  • Locked
[ROM] Dirty Unicorns v10.6 Official 6.0.1 {Angler} (9/9/16)
Replies
4K
Views
426K
matt4321
matt4321
Lexmazter
[TOOL] Lx Multi Tool v1.3.2 [WIN/LIN/MAC][Unlock/Recovery/Stock/Kernel/More]
Replies
486
Views
120K
rcklss1
rcklss1

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 115
    DespairFactor
    DespairFactor
    This is the new refined home for DarkRoom Development. If you submit bug reports without a log, you may be prosecuted...or executed.

    Disclaimer:
    If your device fails to comply with your standards of what you consider functioning, I am not liable. This is provided free of charge and does not come with a warranty. Although, if you provide a log, I can provide some sort of assurance that I will look into your issue.


    Links:



    Source:



    Credits:

    faux123
    franco
    Google
    flar2
    imoseyon
    Cl3Kener
    neobuddy89
    Star Wars


    XDA:DevDB Information
    [KERNEL(Nougat)][ROM]Kylo Kernel/UBERSTOCK, ROM for the Huawei Nexus 6P

    Contributors
    DespairFactor, Cl3Kener
    Source Code: https://github.com/UBERROMS

    ROM OS Version: 6.0.x Marshmallow
    ROM Kernel: Linux 3.10.x
    Based On: AOSP

    Version Information
    Status: Testing

    Created 2015-11-18
    Last Updated 2017-12-28
    View
    33
    DespairFactor
    DespairFactor
    yung40oz84 said:
    I wasn't referring to fixing something that was not broken, I was referring to a way to get the camera gesture to show in kernel auditor, which you have obviously got taken care of with the nodded apk.

    I'm not sure if same post but I was also referring to the speaker volume, which is broken on my end. When I place at 0 gain there is no sound when actually that should be the default level, and it seems like 20 gain is the default level instead. If you need a log I'll be glad to provide. Thanks.

    Sent from my Nexus 6P using Tapatalk
    Click to expand...
    Click to collapse

    I am done with XDA, thread is being closed
    View
    25
    DespairFactor
    DespairFactor
    Packet Schedulers/Congestion Avoidance Algorithms:

    CDG vs. Cubic vs. Westwood:

    CDG
    CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effectively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. During delay-based operation, CDG uses a delay-gradient based probabilistic backoff mechanism, and will also try to infer non congestion related packet losses and avoid backing off when they occur. During loss-based operation, CDG essentially reverts to reno-like behaviour. CDG switches to loss-based operation when it detects that a configurable number of consecutive delay-based backoffs have had no measurable effect. It periodically attempts to return to delay-based operation, but will keep switching back to loss-based operation as required.

    Cubic
    CUBIC is an enhanced version of BIC: it simplifies the BIC window control and improves its TCP-friendliness and RTT-fairness. The window growth function of CUBIC is governed by a cubic function in terms of the elapsed time since the last loss event. Our experience indicates that the cubic function provides a good stability and scalability. Furthermore, the real-time nature of the protocol keeps the window growth rate independent of RTT, which keeps the protocol TCP friendly under both short and long RTT paths.

    Westwood
    TCP Westwood estimates the available bandwidth by counting and filtering the flow of returning ACKs and adaptively sets the cwnd and the sshtresh after congestion by taking into account the estimated bandwidth.TCP Westwood, is a sender-side-only modification to TCP New Reno that is intended to better handle large bandwidth-delay product paths (large pipes), with potential packet loss due to transmission or other errors (leaky pipes) and with dynamic load (dynamic pipes). TCP Westwood+ is an evolution of TCP Westwood, in fact it was soon discovered that the Westwood bandwidth estimation algorithm did not work well in the presence of reverse traffic due to ACK compression. Westwood+ is friendly towards TCP Reno and fairer than Reno in bandwidth allocation.

    Packet Schedulers:

    Why use a non default packet scheduler?
    Packet schedulers are a portion of the kernel that queues network data on a specific interface and governs how they are transmitted and received including buffers. Below I will breakdown a couple of the packet schedulers included in this kernel.

    fq_codel
    FQ_Codel (Fair Queuing Controlled Delay) is queuing discipline that combines Fair Queuing with the CoDel AQM scheme. FQ_Codel uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the bandwidth to all the flows using the queue. Each such flow is managed by the CoDel queuing discipline. Reordering within a flow is avoided since Codel internally uses a FIFO queue.

    pfifo_fast
    The FIFO algorithm forms the basis for the default qdisc on all Linux network interfaces (pfifo_fast). It performs no shaping or rearranging of packets. It simply transmits packets as soon as it can after receiving and queuing them. This is also the qdisc used inside all newly created classes until another qdisc or a class replaces the FIFO.

    A real FIFO qdisc must, however, have a size limit (a buffer size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it receives them. Linux implements two basic FIFO qdiscs, one based on bytes, and one on packets. Regardless of the type of FIFO used, the size of the queue is defined by the parameter limit. For a pfifo the unit is understood to be packets and for a bfifo the unit is understood to be bytes.

    pie
    PIE is designed to control delay effectively. First, an average dequeue rate is estimated based on the standing queue. The rate is used to calculate the current delay. Then, on a periodic basis, the delay is used to calculate the dropping probabilty. Finally, on arrival, a packet is dropped (or marked) based on this probability. PIE makes adjustments to the probability based on the trend of the delay i.e. whether it is going up or down.The delay converges quickly to the target value specified. alpha and beta are statically chosen parameters chosen to control the drop probability growth and are determined through control theoretic approaches. alpha determines how the deviation between the current and target latency changes probability. beta exerts additional adjustments depending on the latency trend. The drop probabilty is used to mark packets in ecn mode. However, as in RED, beyond 10% packets are dropped based on this probability. The bytemode is used to drop packets proportional to the packet size.

    fq
    A packet scheduler is charged with organizing the flow of packets through the network stack to meet a set of policy objectives. The kernel has quite a few of them, including CBQ for fancy class-based routing, CHOKe for routers, and a couple of variants on the CoDel queue management algorithm. FQ joins this list as a relatively simple scheduler designed to implement fair access across large numbers of flows with local endpoints while keeping buffer sizes down; it also happens to implement TCP pacing.

    FQ keeps track of every flow it sees passing through the system. To do so, it calculates an eight-bit hash based on the socket associated with the flow, then uses the result as an index into an array of red-black trees. The data structure is designed, according to Eric, to scale well up to millions of concurrent flows. A number of parameters are associated with each flow, including its current transmission quota and, optionally, the time at which the next packet can be transmitted.

    That transmission time is used to implement the TCP pacing support. If a given socket has a pace specified for it, FQ will calculate how far the packets should be spaced in time to conform to that pace. If a flow's next transmission time is in the future, that flow is added to another red-black tree with the transmission time used as the key; that tree, thus, allows the kernel to track delayed flows and quickly find the one whose next packet is due to go out the soonest. A single timer is then used, if needed, to ensure that said packet is transmitted at the right time.

    The scheduler maintains two linked lists of active flows, the "new" and "old" lists. When a flow is first encountered, it is placed on the new list. The packet dispatcher services flows on the new list first; once a flow uses up its quota, that flow is moved to the old list. The idea here appears to be to give preferential treatment to new, short-lived connections — a DNS lookup or HTTP "GET" command, for example — and not let those connections be buried underneath larger, longer-lasting flows. Eventually the scheduler works its way through all active flows, sending a quota of data from each; then the process starts over.

    There are a number of additional details, of course. There are limits on the amount of data queued for each flow, as well as a limit on the amount of data buffered within the scheduler as a whole; any packet that would exceed one of those limits is dropped. A special "internal" queue exists for high-priority traffic, allowing it to reach the wire more quickly. And so on.

    One other detail is garbage collection. One problem with this kind of flow tracking is that nothing tells the scheduler when a particular flow is shut down; indeed, nothing can tell the scheduler for flows without local endpoints or for non-connection-oriented protocols. So the scheduler must figure out on its own when it can stop tracking any given flow. One way to do that would be to drop the flow as soon as there are no packets associated with it, but that would cause some thrashing as the queues empty and refill; it is better to keep flow data around for a little while in anticipation of more traffic. FQ handles this by putting idle flows into a special "detached" state, off the lists of active flows. Whenever a new flow is added, a pass is made over the associated red-black tree to clean out flows that have been detached for a sufficiently long time — three seconds in the current patch.

    cake
    The CAKE Principle:
    (or, how to have your cake and eat it too)

    This is a combination of several shaping, AQM and FQ
    techniques into one easy-to-use package:

    - An overall bandwidth shaper, to move the bottleneck away
    from dumb CPE equipment and bloated MACs. This operates
    in deficit mode (as in sch_fq), eliminating the need for
    any sort of burst parameter (eg. token buxket depth).
    Burst support is limited to that necessary to overcome
    scheduling latency.

    - A Diffserv-aware priority queue, giving more priority to
    certain classes, up to a specified fraction of bandwidth.
    Above that bandwidth threshold, the priority is reduced to
    avoid starving other classes.

    - Each priority class has a separate Flow Queue system, to
    isolate traffic flows from each other. This prevents a
    burst on one flow from increasing the delay to another.
    Flows are distributed to queues using a set-associative
    hash function.

    - Each queue is actively managed by Codel. This serves
    flows fairly, and signals congestion early via ECN
    (if available) and/or packet drops, to keep latency low.
    The codel parameters are auto-tuned based on the bandwidth
    setting, as is necessary at low bandwidths.

    The configuration parameters are kept deliberately simple
    for ease of use. Everything has sane defaults. Complete
    generality of configuration is not a goal.

    The priority queue operates according to a weighted DRR
    scheme, combined with a bandwidth tracker which reuses the
    shaper logic to detect which side of the bandwidth sharing
    threshold the class is operating. This determines whether
    a priority-based weight (high) or a bandwidth-based weight
    (low) is used for that class in the current pass.

    This qdisc incorporates much of Eric Dumazet's fq_codel code,
    customised for use as an integrated subordinate.


    How to apply a packet scheduler:

    1. Open terminal on your device
    2. Use the "su" command to become root
    3. Use tc to change the packet scheduler(qdisc) on your device. I have included an example below, the first line is for WiFi and the second for data. In the example, we are setting the qdisc to fq_pie, which is a mix of PIE with per flow rate shaping from fq.
    Code: 
     tc qdisc add dev wlan0 root fq_pie
 tc qdisc add dev rmnet_data0 root fq_pie
    4. Confirm your packet scheduler has been applied by using the tc tool again. I have included an example below.
    Code: 
    tc  qdisc

    To use another packet scheduler after applying a previous one, you will need to either reboot or remove the added qdisc from each interface using the command I have included below.
    Code: 
    tc qdisc del root dev wlan0
tc qdisc del root dev rmnet_data0

    View
    23
    DespairFactor
    DespairFactor
    new build is coming with more substratum and theming fixes
    View
    20
    MustBeTrippin
    MustBeTrippin
    Kernel Update - R20

    fixes WiFi issue...

    Download:
    https://basketbuild.com/devs/DespairFactor/Angler/Kernel

    Commits:
    https://github.com/DespairFactor/angler/commits/maul
    View

New posts