On Tue, Nov 8, 2016 at 8:30 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 8, 2016 at 4:45 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> On Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >>> On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson >>> <adamwill@xxxxxxxxxxxxxxxxx> wrote: >>>> On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote: >>>>> A considerable reason why any developer with a laptop would pick >>>>> Windows or macOS these days is because power management is so much >>>>> better, that it's even considered basic. There is no such thing as a >>>>> suspend regression bug on macOS - I've never even heard of such a >>>>> thing let alone encountered it. >>>> >>>> I think you're kind of overselling this because you happened to run >>>> into a suspend regression this cycle. I've been suspending two laptops >>>> and a desktop (with two displays) for the last, like, six years without >>>> significant issues. When I ran into an issue with Rawhide it got fixed >>>> pretty fast. It's really not that awful. >>> >>> In the 4.7 cycle a bunch of Fedora 24 folks got hit with a hibernation >>> regression. I don't know which part you think I'm selling let alone >>> over selling. This isn't limited to suspend or hibernation bugs, but >>> all sorts of other optimizations to get better battery life. I'm in >>> fact not experiencing a battery life problem on this new HP, but on >>> the Mac I do, and I know plenty of people who have crummy battery life >>> running Fedora compared to Windows. So this isn't just about a >> >> It would be interesting to know what hardware they have and workloads >> they are using that are similar between Linux and Windows. The Fedora >> kernel team did some battery life investigations between the two on >> identical hardware and found the differences to be negligible. The >> biggest finding is that streaming video (hangouts, skype, etc) was >> terrible on battery life universally. > > I'd expect the biggest difference to come from use cases with high > idle state. If the CPU or GPU aren't in lower idle states, it'll eat > up battery a lot faster. > > And that's what I see on the Mac, maybe 2.5 hours Fedora and 4.5 hours > macOS. Terminal, texteditor, web browser looking at static pages with > minimal content, using the same ad blockers in the same build version > of FireFox. My suspicion, since top on both OS's shows about the same > idleness, is the discrete GPU isn't being turned off when it could be > on Fedora, where it is automatically on macOS. Your suspicion is likely correct. Hybrid graphics is a known problem. Also "the Mac" still covers a continually increasing set of hardware. > Over on the HP, it's the same workloads as the Mac, and I get pretty > much the same useful life whether Windows or Fedora - but the sample > size for Windows is pretty small due largely to the fact it was blown > away in the first week. > > >>> found early on. When they're looking for particular regressions, they >>> are found early on. Not rocket science. This responsibility also lies >>> with hardware manufacturers, but how can the testing and reporting be >>> made easier, as in, more automated? >> >> Reporting is not the problem. We get tons of reports. It's >> recreating the problem, on the workload the user has, on the same >> hardware. It's about access and data, not reporting. > > I don't understand this. Are you saying that the bug report lacks > basic system information attachments? It lacks specific problem data > collection attachments? Or that there are problems for which the user > can't help upstream, upstream must have physical access to the > hardware? I'm saying getting the low-hanging fruit of basic system information is not the problem. It is getting access to similar hardware and the data around what the workload that is difficult. > Every hardware related bug report I've looked at on kernel.org, > developers routinely ask users for rather obscure information from the > system. The system has this information, but there's nothing that > helps automate its collection and attachment to the bug report. The Ubuntu collects basically a billion pieces of information. It makes the bug report ridiculous. RHEL has something called sosreport which collects similar information but tars it up as an attachment. That's a bit better. > user then has to manually collect what's asked for, and then manually > attach it to the bug report. I see a significant minority of bug > reports where a developer asks for more information and there's never > a response again from the user. That's related what I'm talking about. The reporting of the bug is not the problem. It's the continued follow through from both user and developer that is. A developer is not going to magically fix a PM bug on a machine they don't have when they can't get feedback and information from a user. > This isn't possible with Apple's bug reporter. System information > reports are required attachments, and it contains a lot of information > including power management states, the power management log, system > log, and so on. Yeah, that's something we can do but it won't actually solve the problems. It'll just lower the RTT on the initial triage. josh _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
