They are running stress tests, which is an artificial workload, in order to test the throttle feature. Normal workloads should not do this. The throttle is there in case applications misbehave, websites do too much, or there is a real workload that causes this (such as encoding video without hardware acceleration).
It looks like reducing the frequency during idle is still in progress (devfreq). It might be the case that they had this working from the vendor’s code from months ago, but they are still pushing the code upstream to make maintenance easier. If they switched from a custom kernel to a mainline kernel, then that would explain why power management is all of a sudden an issue. If that is the case, then the work required is just moving code upstream, or going back to a custom kernel.
My gut feeling says, that they are currently waiting for the full prototype, so they have something to show. Then they will mention some unexpected problems with it, and postpone until Q1 or even Q2 next year.
The issue talks about the device ending up at 80°C just from throttling at a 99% rate alone (idle calls itself it seems) At 23°C ambient. So maybe it overheated under the spotlights.
I’ve had an iPhone shut down from overheating. In my case, I was in a hot car, and was running telematics tests. Probably not the best combination I picked up the phone, and it was HOT.
So while it might make me a little nervous to see this in a presentation, I understand it can happen. I have no idea the temperature of the room, but if it was hot and the device was actually doing something, I could see it shutting down.
Aparently a thermal regulating software function for the CPU had a bug present which had both caused excessive heat buildup while consuming extra energy at the same time. Part of energy consumption might represent failure of CPU to cycle down in periods where this was possible while increased heat might also decrease conductance and slow phone function requiring longer times to perform tasks, if only by nanoseconds, but consuming energy nonetheless by requiring longer runtimes. Heat would represent first an energy leak and also a problem of lengthening time for4 processes and time cpu needed to work, both at a loss for battery stored charge.
I hope that this has been resolved.
Yes, it seems less like news if you hear it first from somewhere else, and gets posted later.
I have backed a number of crowd funded hardware, and I have come to expect at least 2 major delays for anything that is not trivial. The fact that they have populated PCBs now is very impressive. They technically could ship when they said they would, if nothing major goes wrong. Mistakes happen, and the schedule does not allow for much room for error. If they were not using off-the-shelf WiFi and cell modem cards, then I would worry about those features. Sometimes, it is all about the suppliers that they work with. It seems like they picked a good one. This is probably the most complex hardware device that I have crowd funded.
If there really is a significant heat/power drainage problem, why haven’t the people using a dev kit noticed it? Or, if they did notice it, why has nobody brought it up in this forum?
It strikes me as somewhat unlikely that a major problem such as this could plague the dev kit for months without it getting a mention or two in this forum…
Is there any official number about how many dev boards have been delivered (or any guess)? And, where all the communication/mail/… between the owners and Purism takes place?
I disagree. The communication around the phone so far has been pretty lousy. Yes, yes, finishing the thing is an absolute priority, but that doesn’t mean there’s absolutely no time left to keep the folks who paid you to create this thing in the loop. Kickstarters for far cheaper products have done better in this regard, informing us every step of the way.
I don’t know about you, but $650 + whatever import/tax I’m gonna have to pay on top of that… That’s the kind of money where I actually expect to be properly informed about all aspects of the product, not just how the libraries that underpin the applications are progressing. And 28 days before the latest possible shipping date (if they’re to hit that Q3 mark), I expect a finalised product design: no more TBD’s in the specs, and an actual prototype of what the final product will look like.
And if you look at how difficult it’ll be to do this product “right” (respecting contemporary form factors, comparable battery life and performance, decent screen/camera, all the convenience apps people expect to find in a phone), how would you explain this lack of transparency? Purism simply sucks at communication? Or that information is intentionally kept from us? And if the latter, why?
I hope my worries will turn out to be unfounded. But at this time, I am getting a little suspicious about the motives for al the secrecy when it comes to the physical aspect of this phone. Now, I’m certainly not applying for a refund. I’m curious to see the final product and to experience living with this as my main phone. So I’m riding this one out. If my worries are unfounded, all the better. If not, well, at least I tried supporting a product that tries to change the world for the better.
I disagree. For one this phone is catering to a crowd of people who actually understand the facets of security within the digital domain. Secondly many people who are concerned about their privacy and security are rather extremely concerned about those things and are also pretty vocal.
If Purism were to be more vocal during the development of the product to include all of the roadblocks, it would do more harm than good. People would speculate without end about everything, and Purism would have to hire staff just to quell the fires this would create.
On top of this, development of this nature is fraught with challenges and roadblocks that are not easy to communicate effectively to the customer. Customers who think they know a lot often times reach the wrong conclusion and are quite vocal about it.
Lastly to use cheap kickstarter projects as a reference for the amount of communication to be expected is unrealistic. The difference in complexity amongst the two are most likely exponential. There is a reason Canonical wanted an insane amount of money to even consider trying to build their own phone, and their phone wasn’t trying to give us hardware based on FOSS principles.
All of this to say that I think the amount of communication we are getting is just right for this type of truly complex product. If they were more vocal they would be making a mistake.
I picked up the phone, and it was HOT.