the first 4 batches preceding evergreen are to be expected to have problems … they are museum pieces after all … but the input that they generate is highly valuable …
3 Likes
yea but battery drain while the phone is off sounds like hw defect, and if this defect is carried to evergreen - this won’t be ever solved by software updates.
8 Likes
Birch: from ~3 to ~6 hours (so far)
I guess that would be >10.5 hours with a 3500mAh battery.
10 Likes
Worth noting that that’s idling with screen and screen, modem, wifi, and usb off. However, that goes for the previous record too, I think, so still a very good improvement.
3 Likes
Hi richi,
Any news from your side? Can you confirm longer usage over the last month?
I am not sure if you already get all the fixes described above by updating but it is worth a try.
Hi howil,
thanks for asking.
Unfortunately, battery run time has been the least of my concerns lately. The mean time between freezes is way below the battery run time.
1 Like
To be exact, the previous record didn’t have USB off (but there were plenty of non-USB related improvements as well :))
5 Likes
What do you people think how much time increase can be reached by optimizing software? We saw a huge increase until now, but something above half day isn’t even close to running a whole week in idle. And since hardware is not as optimized in power usage as other phones I’m not even sure that something similar can be reached with only software optimization.
But I’m also no expert. So what do you think is possible with a well optimized software? 1 day idle? 3 days? Is it even possible to evaluate it with the information we got until now?
1 Like
My guess is that this will not ever be realistic with v1.
It is better to measure than to speculate.
2 Likes
Whats wrong with speculate by using technical knowledge (what I think some people here have)? Just from reading Purism it sounds like “we have almost optimized easiest and most effective things and we reached an up-time about 14h - anything more will need a lot more work with a lot less effect”. It sounds like more then 1 day isn’t possible with v1.
But I also know that I miss a lot of information about “what can be done further to optimize” and I also cannot evaluate at which point of optimization we are in real currently. I don’t care much about 100% correctness, but I care about more information since it’s 2nd most important thing I want to know (first important is data security and open source hardware).
You might have heard of the Pareto principle or 80/20 rule.
It’s very general, and in my own experience I constantly find it to be true: You get 80% of the results with 20% of the work, and vice versa.
I assume, this is about the state of Librem 5 power optimizations: All relatively simple things have already been implemented and most future optimizations will only have little effect.
It’s very unlikely to double the standby time from now on.
The bigger battery will have the biggest effect.
In theory, a lower boundary for energy consumption could be calculated - a boundary that can never be crossed: Turn off all non-essential components, assume lowest power state for essential components like CPU, RAM. I guess those two are the biggest anyway (display off), and if you calculate the lowest possible consumption for those two, you can define such a lower limit.
As I said, I’m almost certain that this lowest limit is more than half of what we currently have, so runtime cannot possibly double, except with a bigger battery.
2 Likes
Thanks for your reply. I know the principle even if I didn’t know its name. Something similar was the reason to ask this.
But I thought CPU and RAM usage in stand-by can maybe reduced even more with software optimization. So this counts to the things with lower effect in your opinion?
If so we can say the huge difference between Librem 5 and any Android phone is not the OS optimization. It is more a hardware problem. I mean a 28nm CPU needs more energy then 14nm or even 7nm and the all-in-one SOCs are even more efficient (while using it). Even my old Android 2.6 phone with 1700mAh battery has over a week up time. I just didn’t know that this makes so much difference.
However, I think these things will be better with future phones. But we need to start at some point, so it doesn’t change my mind to this project.
With Apple’s switch to ARM, maybe what I’m about to say is a little easier to understand. But the important thing to remember with the L5, is that, unlike any of the current smartphones on the market, it will be running mainline (IE: desktop) Linux. Not a mobile specific OS.
14 hours for a full up computer in your pocket is more than acceptable. I can wake up, unplug it from charging, go to work, use it, and then (assuming I got up at 6 am) as long as I’m home before 8pm, I’ll have made it through an entire day.
Now unlike my laptop or desktop, the L5 is also a phone, with a cellular data connection. It is working with more radios than most laptops or desktops.
I mean if the 14 hours is legit, than I would be one of the people, saying Purism has reached mission accomplished.
That doesn’t mean stop working to improve that, just that, this is a good milestone.
2 Likes
I never doubt about it. But at this point you cannot use it in these 14h. Maybe to check the clock or such little tasks in between it’s okay. No calls, no connection to modem (modem costs around 2h). So i don’t think that’s usable as daily driver right now, but it is close before.
I thought a desktop Linux with great mobile optimization would be not so much difference compared to a mobile specific OS on same hardware. Was I wrong? If so, it could be interesting to use a dual boot system to have something more efficient for daily usage and pureOS for specific use cases.
1 Like
PureOS is the only desktop Linux distro that is built with the purpose of monitoring several radios and sensors (cell modem, proximity sensor, light sensor, etc) constantly. Its largely uncharted waters for Linux, not so for android and Apple. Mobile optimization is good, but there are things that have to be taken into account that no desktop OS has ever had to worry about.
I don’t think I’m.wording my point very well, but hopefully you see what I mean. And hopefully my deduction comes across as sound.
These features are not new for Linux, there are lots of embedded devices out there doing this but they are usually not based on a desktop distro. So the infrastructure is there, it’s just a matter of putting it all together like all the embedded distros doing the same have done.
I work for a company who has a OpenEmbedded distro and an almost mainline kernel with a device which has a camera, gps, microphone, display, accelerometer, gyro, wifi, bluetooth etc. and the majority of our stack is open source and we upstream as many changes we can upstream to remove having to maintain local patches so we can have up to date packages.
4 Likes
This is interesting. I see it where I work also, that it’s becoming more common in recent yeasr for companies to strive for upstreaming for such reasons. I’ve been wondering what this change means for companies, I think it probably means the value of a company shifting away from lots of closed-source code owned by the company, towards a new situation where the value of a company is more in the competence of its employees and its ability to keep those employees and attract new good ones.
I think this is a good development, even if the FSF would say it is not enough, they want copyleft licenses which the companies don’t care about.
No, it’s the other way around: If you assume the lowest power state for CPU+RAM, then software optimizations rather help you to get closer to that theoretical ideal. A typical software optimization is trying to reduce the times that the CPU has to wake up from it’s sleep state. A bad piece of software would set a timer to every second (or worse: 100 times a second), that would then wake up the idling CPU, ask “is there new data for me?”, get a “no” reply, and thus waste a lot of energy. This is called polling. Whenever possible, polling should be avoided. It’s usually possible, to register for events and then only be woken up if those events happen. (Just a simplifed, general example).
I completely agree. I think the natural step for a company embracing open source is to first start using open source software, the second is to start contributing to open source projects and the third is to open source their own software themselves. I’m happy to see how both the company I work for and others are slowly progressing. I’m also happy to work for a company which previously only pushed open standards to now also start open source some of their code. It’s going slowly, but progress is being made.
I believe that the more companies that follow this path will create a much healthier industry. Not only pushing solutions internal to the company to be better but also show that even competitors can be stronger together and make better products when we all contribute. When people realize that open sourcing is a business advantage is when we will see big progress, but that won’t happen if only a single company is contributing and it’s hard to get competitors to work with you instead of against you even if it’s for the benefit of both.
2 Likes
I think we’re talking past each other. I didn’t spoke about theoretically lowest power state. I spoke about the Librem 5 right now and as far as I know it’s polling isn’t fully avoided yet. Tell me if I’m wrong. Interesting explanation though.