Lots of blame here attacking CR and Apple, personally I think it is great that they got together and fixed the issue. I'd like to see more of this kind of approach to solving problems rather than the constant blame games that go on.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Consumer Reports Reverses Course, Recommends MacBook Pro Following New Testing After Apple Bug Fix
- Thread starter MacRumors
- Start date
- Sort by reaction score
At the end of the day you use the machine and see how it's suits you and not how you suit it . I bought 2015 and 2016 at the same time and returned the 2016, cause it lacked value for money. Had the prices been the same I'd probably have kept the 2016. Though really unhappy with stupid touchbar and accessibility/usability issues it brings
[doublepost=1484296914][/doublepost]
Yeah, I'm a CR stockholder..... trying to save their credibility from objective apple fans.
Don't really know. I saw the Henge reference in an article here on MR the other day regarding new stuff at CES.
But the Henge TB3 dock is $375 (!!!) That makes the $279 OWC TB 3 dock seem positively inexpensive!
I'd actually be tempted to do the USB-C version of the Henge dock. IIRC, it is "only" $199, or the TB2 version of the OWC dock (using the Apple USB-C to TB2 adapter) which is $219.
But there are gobs of assorted USB-C docks on Amazon in the $10 - $100-ish range, depending on what ports you need. The one I would take a look at is $70, and has (three) USB 3.0 ports, plus Gigabit Ethernet, 4k HDMI, SD and MicroSD Card Reader, and a USB-C pass-through for Charging without "wasting" another USB-C port. It's small enough to pack along (at that price, buy one for home/office and another for on-the-go). It is also available in Silver or Space Grey (ahem!), and requires no drivers for the 2016 MBP (a lot of the cheapie multiport docks require an Ethernet driver to be installed. This one doesn't). The HDMI is only 30 Hz at 4k (probably 60 Hz at 1080p); but that is par for the course with these small docks, and shouldn't be a problem unless you are gaming. Plus, it looks nice, being aluminum and all...
https://www.amazon.com/Satechi-Aluminum-Multi-Port-Adapter-Ethernet/dp/B01FWT7MEA/
Only negative is that the Ethernet port may not be that fast. But depending on what you are usig it for, that may not be that big of a problem. There are plenty of other choices though; just be careful and read the reviews for hidden "gotchas" or reliability issues...
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
I still think this manner of testing is not valid. Turning off caches may have very different effects on different browsers and operating systems.
CR should build a test environment where servers control caches (via standard "Cache-Control", "Last-Modified", and "Expires" headers), simulating real-life browsing conditions more accurately.
CR should build a test environment where servers control caches (via standard "Cache-Control", "Last-Modified", and "Expires" headers), simulating real-life browsing conditions more accurately.
Complains that battery life is too low, yet wants a quad core i7 in the 13" model. :lol:
Doing what? I'm doing basic software development, and my battery lasts about 8 hours of continuous use (more than my typical work day). I build iOS apps with XCode, web apps with Chrome and Safari. I also develop machine learning software, but that's in the cloud (doing that **** on ANY laptop would be insane). I have MySQL, ElasticSearch, uwsgi, Celery, nginx, and whatnot running in the background all the time.
I would love to know how you can actually deplete your battery in 3 hours, and do you really run that kind of workload all the time?
Last edited by a moderator:
Maybe they forgot to divide by the number of samples when they calculated the average
Beginner's mistake...
Last edited:
Stop imagining, start testing. Do you have one? We have several in our office. It runs idle with the screen off for days.
Anyway, the CR test method is broken, and doesn't reflect real life use. It shows, though, that you can run the 2016 MBP in a loop, rendering the same web pages in Safari, for a very long time indeed. I have no doubt that whatever CR measured, actually happened.
Will you get the same battery life in your real-life browsing? Probably not, because CR is not testing a realistic scenario.
My tbmbpro 13 drains in 3-5 hours just doing random stuff like safari browsing, some photos editing/sorting, mail, music listening and some videos.
It's on wifi, has Bluetooth on and screen brightness at 75% as I find the recommended 50% way to dark usually.
[doublepost=1484300509][/doublepost]
Ok, I'll get coconut battery. Was wondering what app you guys were using to get these wattages.
I've been keeping an eye on activity monitor, and didn't see anything that stood out to me.
What would you say, on the 13" tb model, how many percentage points should it go down within one hour, doing regular stuff?
Last edited by a moderator:
Easy.
- Set screen brightness nice and low. The screen is a big power hog. The lower you go, the more battery life you get. CR uses 100 nits, which is REALLY LOW.
- Have nothing running in the background. Spotlight, encryption, backups, dropbox, drive, 1password, backblaze, adobe and microsoft updaters, none of that.
- Turn off bluetooth.
- Don't even connect your iCould, email, calendard, whatnot. Use factory settings.
- Set up a test where most of the time the machine is waiting (like waiting for a web page from a server!), just like the CR page reload test.
- Make sure step 4 keeps the touch bar off. It drains some power in real-life use, I'm sure the CR test has the touch bar time out and turn off.
- Keyboard backlight off.
- No audio. No video. Just reloading a web page in Safari, every few seconds. NOTHING else.
Representative of real-life use? Not even close. But it's quite possible to have a MBP run for 14-15 hours "doing something".
[doublepost=1484301032][/doublepost]
You shouldn't be afraid. Automated testing will still help you a lot! Just don't get lulled into a false sense of security: automated testing is very useful, but it is not flawless. It takes quite a lot of effort to build automated tests that accurately reflect real-life usage.
It's true, I did about the same, following the Instructions from Apple Hotline and i did get about 15 hours (of doing nothing.) just minus the webpage. It was just sitting idle on the desktop. And I think wifi was off.
I have to admit that I'm struggling with this.
On the one hand the publication absolutely should publish the story when it identifies a major flaw in a product. That's public interest and the right thing to do,
However, in this case there was clearly a big anomaly between Apple's claims and the publications' findings -- and Apple was speaking with them about it (i.e.. not denying it, not admitting it, just wanting to confirm it) -- so in that situation was it appropriate to publish then -- or should they have waited to work with manufacturer.
Some argue that the problem was Apple's -- it was a Safari bug -- and as the product was available for sale the public had a right to know --
My problem is drawing the line -- because it also felt like a big sting -- so I must ask if the testers knew about the safari flaw before they developed the test, in which case it was a hit.
And I think there is a public interest argument in learning if that was the case.
What does everybody else thing?
**Edit to add: Written on a nice new MacBook Pro -- which in my experience -- well, I've not had to charge it all week. I think it's an excellent machine.
On the one hand the publication absolutely should publish the story when it identifies a major flaw in a product. That's public interest and the right thing to do,
However, in this case there was clearly a big anomaly between Apple's claims and the publications' findings -- and Apple was speaking with them about it (i.e.. not denying it, not admitting it, just wanting to confirm it) -- so in that situation was it appropriate to publish then -- or should they have waited to work with manufacturer.
Some argue that the problem was Apple's -- it was a Safari bug -- and as the product was available for sale the public had a right to know --
My problem is drawing the line -- because it also felt like a big sting -- so I must ask if the testers knew about the safari flaw before they developed the test, in which case it was a hit.
And I think there is a public interest argument in learning if that was the case.
What does everybody else thing?
**Edit to add: Written on a nice new MacBook Pro -- which in my experience -- well, I've not had to charge it all week. I think it's an excellent machine.
You've picked the right word in your railroad of praise. YOU THINK. It also happens to be a heavily compromised, overpriced workstation that no Pro I know or heard of has enjoyed working with. I know developers fed up with the dongle labyrinth and to whom the TouchBar mishaps cause anxiety, designers whose frozen MBPs need be let to run out because the TouchID/Power button is unresponsive, and copywriters who can't get used to the keyboard after weeks of use.
The prevailing sentiment seems to be: "If i was spending my own money instead of my employers, i would look elsewhere"
PS. "The best laptop Apple has produced" is a moot, use-case specific point. For me, as a designer and video editor, it was the previous MBP retina gen. By a long shot.
Agreed, it's never a bad thing to find a software bug.
In this case, however, the big variability in the test results should have alerted CR to work with the manufacturer before publishing results.
In the software security circles, we have a thing called “responsible disclosure”. It means that if a security researcher finds a security vulnerability, the ethical thing to do is to contact the vendor and work with them to have it fixed. When a fix has been available for a while, it's OK to go public with the vulnerability to claim credit for your work.
The same principles should apply for CR and other entities with a similar role. If there's a finding that is wildly different from the vendor's claims, CR should have worked with the vendor to figure out what the problem is (and if it will affect the majority of the public) before going public with it.
The bottom line is that security researchers will lose their clout and credibility if they go public without responsible disclosure. The same sort of rules should apply to testing that isn't about security, and CR just lost a great deal of clout for this.
Last edited by a moderator:
God so many people aren't getting the point here.
The point of so called "benchmark" or "standardised" tests is for comparison. E.g. if battery A performs twice as well as battery B under test conditions, you can probably expect battery A to perform twice as well as battery B under your working conditions.
The point of so called "benchmark" or "standardised" tests is for comparison. E.g. if battery A performs twice as well as battery B under test conditions, you can probably expect battery A to perform twice as well as battery B under your working conditions.
How about you read what I wrote. Perhaps if apple put slightly less emphasis on it being so razor thin, they could deliver both. Give us one or the other, battery improvements with dual core processors or quad core processors. I'd be happy with a lack of battery improvement if it meant a real jump in performance like quad core for the 13, I'm not happy wirh same or less battery life because the battery is smaller due to them shrinking the chassis again.
You are also not getting the point, Brian.
Safari is completely different from, say Chrome, IE, or Firefox.
There is no standard to "turn off caching". Whatever settings seems to do that, are you sure it does the same exact thing in all browsers?
No? Didn't think so.
Know what actually should do the same thing in all well-behaving browsers? Server-side caching headers sent from the servers to the browsers. Going forward, CR should use those instead of nonstandard browser settings (meant for developers and QA!) to control caching behavior.
Last edited:
Where am I blaming CR? I just say that they did shabby work, and released a recommendation (or lack thereof) in spite of having inconclusive results. My point is that CR's original article is not informative and therefore useless. If I were to blame someone then it would be people who blew that story out of proportion.
Sure, lets abandon all objectivity and simply believe anything anyone with some authority says! I am happy that you are this trusting, but I'm not. In fact, if that is your point, why are you even arguing with me? I am a PhD, university lecturer, author of dozen+ successful papers and a well-regarded expert in my field by the scientific community. Certainly I quality as an 'authority'.
Hint: don't trust anyone. Don't trust me, or CR or Apple. Use your own head. Its there for a reason.
And yes, Apple and other reviewers describe their testing methodology in detail
I am not arguing with that. I am arguing with the very methodology. The ultimate problem is in the way they design their experiment. Bugs notwithstanding, turning browser cache off is not a proper way to emulate reloading different websites. Its not that difficult to implement randomised URLs on the server side, and that would emulate this scenario MUCH better.
Now you are just inventing stuff. Both Apple and CR are very clear that the weird results CR got was due to a bug with disabling the cache. Where do you have that statement from?
That is just idle speculation on your part. The battery life might or might not have increased and if it did, that could be due to myriads of reasons. The beta update most likely included more than one bug fix.
BTW, main suspect for bad battery life are still third-party apps. You'd be surprised how many apps I've seen that needlessly trigger high-power graphics because the devs were too lazy to add a single line to their configuration.
I would say you're half right. Unicode may design emojis but apple has to then implement them into iOS using the graphical style they want. Considering Apple spent time redesigning all the emojis for iOS 10.2 with more realistic and vibrant finishes, then spent time changing the peach butt emoji from the 10.1 version to a totally new version in 10.2 beta1 and then redesigning it back to the 10.1 version with the 10.2 look, that to me is a fair amount of work for a superfluous thing. https://www.macrumors.com/2016/11/15/apple-peach-emoji-ios-10-2-beta-3/
So I tend to agree with the person you quoted in your post. Unicode may come up with emojis, Apple then has to design them for iOS - which to me seems they spend a lot of time doing.
So, interestingly there are 2 stories this week of reports being published, leading to discussion of what should get printed and what shouldn't.
Perhaps America's next president has a bug - which will be fixed in the next software update?
What you actually do on a machine while it's under battery power can make and absolutely massive difference. Modern computer hardware is very energy efficient and much of this is achieved by powering down or slowing down parts of hardware that aren't being used. As a result there's an absolutely vast difference between how much power parts draw when they're not doing much and when they're going full tilt. In this case it was a bug in the "do not cache" setting that caused the browser to keep re-downloading the same assets over and over again even between page loads.
I have a feeling that what happened was that part of the caching functionality in Chrome simply didn't get the message and tried caching parts of the pages over and over again without success.
I once tried to use Chrome on my 2011 model and it almost halved my battery life when compared to Opera. Not sure of the exact effect on the 2016 model, but if what I saw is anything to go by, the fault for your sub-par battery life lies with you and Google rather than Apple.
Last edited: