Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Apple publiceert bètapatch die accuduur MacBook Pro's uit 2016 moet verbeteren

Apple heeft de problemen die leiden tot de opvallend korte accuduur in de nieuwste MacBook Pro's naar verluidt verholpen in een bèta-update. Dat meldt Consumer Reports, de Amerikaanse consumentenorganisatie die de laptop wegens het euvel niet volledig aanbeval.

Het was voor het eerst dat Consumer Reports een Apple-laptop niet volledig aanbeval. De resultaten van de eerste accuduurtests leverde accuduren op variërend van 3,75 uur tot 19,5 uur. Dat waren de meest inconsistente resultaten die de organisatie heeft gemeten van alle 140 laptops die de revue gepasseerd zijn. Volgens een bericht van de organisatie is de bèta-update geïnstalleerd op dezelfde MacBook Pro waar Consumer Reports eerder zijn accuduurtests op uitvoerde. Die proeven worden nu herhaald en de organisatie gaat die publiceren wanneer ze gereed zijn.

De bug zat genesteld in Safari. Consumer Reports schakelt via een verborgen instelling namelijk de cachingfunctie uit bij zijn browsertest. Hierna kan de organisatie herhaaldelijk dezelfde webpagina laden zonder dat deze uit de cache gehaald wordt, wat een betere nabootsing is van echte gebruiksomstandigheden. Juist deze instelling activeerde de bug blijkbaar. Het is een van meerdere instellingen die Consumer Reports aanpast voor zijn accuduurtest. De organisatie heeft de test ook al herhaald zonder aangepaste instellingen en toen was het resultaat consistenter en wel naar verwachting.

Consumer Reports tekent zelf wel aan dat er ook consumenten zijn geweest die op fora hun beklag hebben gedaan over de korte accuduur van Apples nieuwste laptop. Het is echter onwaarschijnlijk dat deze consumenten ook via de verborgen instelling de cachefunctie van Safari uit hebben geschakeld. Aangezien Apple zegt dat het probleem met de accuduur daar vandaan komt, is het niet zeker dat ook deze gebruikers van hun accuduurproblemen afgeholpen worden.

De update die de bug in Safari verhelpt, is nu beschikbaar als update 10.12.3 bèta 3. Deze kunnen gebruikers bemachtigen door zich in te schrijven voor het bètaprogramma van Apple. Na enkele weken testen, zal de update verspreid worden onder alle gebruikers van de nieuwste MacBook Pro's. In een eerdere update had Apple al de schattingen van de resterende accuduur uit macOS gehaald.

Door Mark Hendrikman

Nieuwsposter

11-01-2017 • 08:13

122 Linkedin Google+

Reacties (122)

Wijzig sortering
Ik begrijp de commotie niet helemaal.
Consumer Reports wijzigt een verborgen instelling, om een realistischere test uit te voeren.
Dit op zich is een grote fout. De gemiddelde gebruiker laat die instelling voor wat ze is; dus die test is (duidelijk) niet representatief.
Daarmee is de kous af wat betreft de resultaten van CR.
Dat deze bugfix nu uitkomt is leuk voor mensen die willen benchmarken, maar hier komt de gemiddelde eindgebruiker niet mee in contact...

[Reactie gewijzigd door efari op 11 januari 2017 09:22]

Naast de argumenten van de andere reacties voor het wėl realistisch zijn van de test, wordt deze test ook nog eens al jaren op deze manier uitgevoerd. Aangezien de vorige MacBooks daar prima doorheen kwamen, is er wel degelijk iets mis met de nieuwste.
OK, akkoord dat een CR test wel representatief kan zijn ten opzichte van alle andere voorgaande CR testen. (want als je plots je testmethode gaat aanpassen, kan je onderling niet meer vergelijken; dat klopt)

ik blijf het gewoon bizar vinden.
Als iemand een realistische test wil uitvoeren. voer 'm dan gewoon 'realistisch' uit. letterlijk zoals je in the field zou doen... (en niet met synthetische tests)
Zoals reeds aangehaald kan dat niet. Stel dat je honderd verschillende live websites bezoekt. De kans dat je bij een volgende testrun identiek dezelfde paginas krijgt is nagenoeg nihil waardoor elke vergelijking waardeloos wordt.
Kan wel, is alleen iets meer werk.
Je kunt bv in je hosts file die 100 domeinen naar jouw eigen server laten verwijzen en die dan netjes achter elkaar testen.
Hoe vaak bekijk jij 13 uur achter elkaar dezelfde webpagina op je laptop die je dan ook nog constant refreshed?

Ik vraag me af of je het nieuwsartikel wel gelezen hebt, hierin staat namelijk heel duidelijk "Consumer Reports schakelt via een verborgen instelling namelijk de cachingfunctie uit bij zijn browsertest. Hierna kan de organisatie herhaaldelijk dezelfde webpagina laden zonder dat deze uit de cache gehaald wordt, wat een betere nabootsing is van echte gebruiksomstandigheden."

Nu zou je kunnen stellen waarom gebruiken ze dan geen verschillende websites achter elkaar, dit zou wel realistischer zijn maar lastiger te herhalen bij een volgende test aangezien websites wijzigen in de tijd en dus in theorie meer/minder resources kunnen gebruiken.
een beter nabootsing van echte gebruiksomstandigheden zou zijn:
cache laten aanstaan, en een waslijst aan webpagina's laden, hier en daar een link volgen...
de gemiddelde gebruiker bezoekt wel minstens 1 keer dezelfde pagina meermaals.
dus cache uit is wel degelijk non-representatief...

betreft uw 2de punt: lastiger te herhalen inderdaad, maar wél representatief. so what dat de websites wijzigen? het gedeelte van de website die gelijk blijft, is gecached (DAAR DIENT HET VOOR), de rest wordt opnieuw geladen. en dat is voor elke gemiddelde gebruiker (die de cache aan laat staan) gelijk.
zonodig moeten CR hun test 50 keer uitvoeren en daar het gemiddelde van nemen (iets wat ze toch al doen, denk ik)
Maar een echte gebruiker surft naar meer dan 1 enkele pagina. En wil je verifieerbare resultaten dan kan je bijna niet anders dan telkens dezelfde pagina gaan inladen zonder cache. Het enige alternatief is een omgeving opzetten waarin je honderden tot duizenden sites hebt die statisch blijven.

Want in dat laatste heb je net het belangrijkste: om een eerlijke vergelijking te maken moet in elke test identiek dezelfde content gedownload worden. Download je slechts enkele MB meer heb je meer energie nodig voor de verbinding, de CPU moet meer data verwerken, het geheugen moet meer data opslaan en ga zo maar door. Die fluctuaties wil je er zoveel mogelijk uit.
Hopelijk is die webpagina geen random pagina van internet... Ik zou niet graag de statistieken van het aantal hits of bezoekers zien als ze zo'n test uitvoeren.
Je krijgt dan op het moment van de test een hele goede score en de volgende maand zie je dan dat er maar 10 hits zijn...
CR wijzigt een verborgen instelling, om een realistischere test uit te voeren.

Realistischer = dichter bij het gemiddeld gebruik.
Benchmark = een vastgestelde test methode die niet altijd realistisch is. Zoals bv batterijverbruik bij CPU 100% over meerdere uren.
dichter bij het gemiddeld gebruik.
Maar is dat realistischer als niemand die verborgen debug setting gebruikt?
Het is geen debug setting. Het is een setting die je gewoon kan en mag gebruiken. Cache wordt gebruikt om te besparen op netwerkverkeer maar er is geen enkele verplichting om je cache te gebruiken.

Het uitzetten van die cache (wat in principe geen enkele invloed mag hebben) zorgt ervoor dat je met enkele paginas een veel realistischere browserervaring kunt simuleren met slechts enkele paginas. Een test die op honderden notebooks goed gaat en hier niet.
Het uitschakelen van de cache heeft in principe altijd invloed omdat het hele idee van de cache is om het laden (en in sommige gevallen het synthetiseren) van resources omlaag te brengen.
Het is geen debug setting
Het zit onder het normaal uitgeschakelde 'Debug' menu.
De debug setting cleant de cache/weigert gebruik van de cache. Hoewel dit debug is, moet je de cache wel uitzetten bij durability tests, zoniet kunnen alle assets gewoon uit de RAM geladen worden en hoeft geen netwerk/hdd/cpu kracht verloren te gaan. Over enkele uren is dat niet verwaarloosbaar. Normaal gebruik zal verschillende website aandoen en hoewel een deel zeker gecached kan worden, zal het verre van 100% zijn zoals anders bij deze test zou gebeuren. Dus de test is zeker niet slecht opgesteld, waarom de laptop hierdoor zo slecht presteerde zou zeker een interessant verhaal zijn.
Ze wijzigingen deze instelling omdat het makkelijker is. Zonder cache altijd dezelfde site laden of met cache altijd een andere site laden (wat je in werkelijkheid doet als consument) is hetzelfde. En aangezien ze een site laden die nooit veranderd kunnen ze een consistentere test uitvoeren op alle apparaten.
wat je in werkelijkheid doet als consument is een website laden, en daar de links volgen op die website.
als je op hetzelfde domein terecht komt, kan je uit uw cache gaan lezen...
als je op een ander domein terecht komt, gaat uw browser voor bepaalde zaken (jQuery) alsnog uit de cache gaan lezen...
Oh dus de standaard gebruikssituatie is dat alles op-voorhand is gecached? Niet dus.... daarom is het juist wel een goede nabootsing... het doet mij tevens wederom afvragen niet alleen hoe maar ondertussen óf apple zelf nog producten test, het zou namelijk juist nergens op slaan om dat met gecachede gegevens te doen.

Maw; Apple had bij een gedegen testproces deze bug allang aan moeten treffen.
Safari? Dat gebruik ik niet eens. En mijn 15" MBP met touch bar haalt nauwelijks 5 uurtjes. Scherm op halve helderheid en verder niets bijzonders. Best waardeloos. Nu zit ik nooit zo lang zonder stroom maar als ze bijna 20 uur beloven is maximaal 5 haalbare uurtjes wel een belediging, zeker voor zoveel geld.
Gebruik je Chrome? Dit is (vooral op de MBPt) een battery hog, omdat heel vaak de externe GPU ingeschakeld wordt, wat volledig onnodig is voor bijna alle websites. Als je Opera gebruikt, heb je dezelfde engine als Chrome, maar wordt standaard niet de externe GPU gebruikt (tenzij je dat zelf inschakelt in de instellingen). Dat scheelt al vaak een paar uur.

Disclaimer: ik ben Mac-developer voor Opera en heb een MBPt :)
Klopt, de rendering engine van Chrome forceert dat. Ook apps die dat embedden zoals middels Electron doen dat.

Dit kun je uitzetten.

Ook kan ik het programma gfxcardstatus aanraden. Vooral als bovenstaande optie niet helpt.

Dit zijn overigens retina MBPs. Alle 2016 versies zijn dat. Bij mij kost Chrome juist helemaal niet zo veel stroom om te browsen.

[Reactie gewijzigd door Jerie op 12 januari 2017 17:58]

Gebruik je veel Chrome om te browsen toevallig? Die schijnt erg veel stroom te vreten. Ironisch genoeg zou juist Safari erg zuinig moeten zijn (als deze bug niet roet in het eten had gegooid).
sja, nadeel is wel dat de helft van de websites dan niet fatsoenlijk werkt.... wat een dramabrowser is safari zeg!
Dit is echt een rare reactie. Ik ken bijna geen enkele site bij het surfen die problemen heeft met safari. In het begin (2010) waren er wel een websites die problemen hadden. Maar dat had meer te maken met die rare windows activeX componenten. Wie gebruikt dat nog in deze tijd waar meerderheid surft met mobiele browsers?
Nou het feit dat safari genoeg html5 componenten niet ondersteund? 8)7

De reden dat een boel site's wel werken in safari zoals het hoort is omdat de developers regelmatig workarounds inbouwen omdat safari dat blijkbaar nodig heeft.

Kort voorbeeld, de html5 form "required":
https://stackoverflow.com...d-attribute-how-to-fix-it

http://www.w3schools.com/tags/att_input_required.asp

Beetje raar he?
Chrome, Internet explorer, firefox, opera, alles heeft support voor deze attribute, behalve uiteraard, safari.


@Offtopic:
Het is de internet explorer uit de jaren 90, maar dan nog up-to-date en wordt zowel op de telefoon als computer bij iedereen door de strot gedrukt., zeker op de iphone's. Waarbij het als verplichting is om Apple haar safari engine te gebruiken.
Trouwens dat is opgelost in de laatste Technology Preview. Maar goed, vervelend maar niet echt storend...
Het gaat er niet om dat niet alle specs volledig ondersteunt worden. Het gaat erom of je dat in de praktijk merkt.... Ik gebruik ook safari en merk in de praktijk niet dat bepaalde dingen niet werken. Zal wellicht afhangen van je surfgedrag. Maar enkel aan tonen dat bepaalde html5 componenten niet werken vind ik wat kort door de bocht.. als er geen sites zijn die die componenten in producten hebben, maakt het in de praktijk niets uit.
Maar niemand weet een site aan te geven die niet werkt. Dus er is helemaal geen probleem van "Safari werkt slecht"
>zeker op de iphone's. Waarbij het als verplichting is om Apple haar safari engine te gebruiken.

Thank god. Stel je voor dat elke app zijn eigen keuze voor browserengine mag maken. Doei batterij! Je vergeet dat ik 1680MAh heb. De reden dat ik daarmee 2 dagen kan is omdat Apple dit soort beslissingen maakt. Ik heb géén behoefte aan chromium, niet alles hoeft te smelten van hitte.
Ik gebruik al jaren Safari full-time op Mac en kom eigenlijk nooit meer een webpagina tegen die slecht of helemaal niet werkt. Laatst een issue met diesel.com (kledingmerk) maar dat had met de adblocker te maken waardoor ie het ook niet onder Chrome deed. Uitschakeling daarvan loste het probleem op.
Ik gebruik nu 6 jaar safari. Ik surf vrij intensief. Voor mijn werk en prive. Maar nog nooit een site tegengekomen die niet goed werkt. Heb je een voorbeeld site?
Dan zouden iPhone en iPad gebruikers het halve web niet kunnen gebruiken? Lijkt me zeer onwaarschijnlijk. Zelf merk ik helemaal geen verschil tussen Chrome en Safari. De enige reden dat ik Chrome toch nog wel eens gebruik is ivm specifieke Chrome extensies.
Werkt altijd perfect bij mij, ik zou niet weten welke site niet werkt. Heb je voorbeelden?
Dikste bullshit ever. Iedereen die zeikt over batterij op Mac gebruikt geen safari. Ik haal daarmee 2 of 3x zo veel batterijtijd dan met Chrome.
MacBooks moeten met safari worden gebruikt. Verbruikt veel minder gpu/cpu. Je mac is stiller en loopt soepeler. Mijn eigen MBpro haalt ongeveer 9-11uur.
MacBooks moeten met safari worden gebruikt.
Ook mijn MacBook is inderdaad stiller en koeler met Safari i.p.v. Chrome. Echter, omdat ik op zowel Windows, Linux en MacOS werk en zakelijk de Google G-Suite (voorheen Google Apps for Work) gebruik, heb ik toch wel een behoorlijke voorkeur voor Chrome.

Chrome is beschikbaar op alle drie de genoemde platforms.
Chrome ondersteund meerdere accounts, zodat ik snel en gemakkelijk kan wisselen tussen mijn zakelijk en privé account (inclusief bookmarks, chrome-apps met bijbehorende accounts)
Chrome werkt erg soepel met de G-Suite

Onder Linux en Windows lijkt Chrome ook veel minder een batterijverbruiker dan onder MacOS... Ongetwijfeld zullen Google en Apple hierin qua oorzakelijkheid wel voornamelijk naar elkaar wijzen; de waarheid ligt meestal in het midden.
Als je wilt switchen tussen zakelijk en prive, zou ik kiezen voor zakelijk Chrome en prive Safari. Het is waar je locked-in wilt zijn: Firefox, Safari, Chrome? Ik kies liever voor Apple, waar ik niet het product ben, en waar alles samenwerkt met al mijn Apple apparaten, én waarmee ik 12h batterij haal.
Op zich is het draaien van verschillende browsers voor het onderscheid zakelijk/privé natuurlijk mogelijk (op Windows en MacOS in elk geval), maar dan heb ik in de praktijk dus altijd in elk geval Chrome open. Daarmee handel namelijk ik niet alleen mijn zakelijke mail e.d. af, maar omdat onze webapps door onze klanten juist vooral in Chrome worden gebruikt en de IDE voor debugging de default browser opstart, moet deze voor mij op Chrome staan.

Het zou voor mij ideaal zijn als er een dag komt waarop Chrome onder MacOS gewoon net zo behoorlijk draait als onder Windows of Linux. Zo moeilijk zou dat toch niet moeten zijn...

[Reactie gewijzigd door resma op 11 januari 2017 16:25]

Waar vind je die belofte van 20 uur terug? Ik kan me maximaal 9 a 10 herinneren namelijk.

Ik moet zeggen dat de accuduur vooral waardeloos is zodra er een extern scherm aangesloten is, de AMD gpu slaat dan aan en dat vind ik jammer. Die on-board Intel kan toch wel het retina display + een extern fhd scherm aansturen? (antwoord is ja, dit kan de 13 inch pro 2016 namelijk wel). Voor de rest ben ik een zeer tevreden gebruiker van de 15 inch mbp2016 hoor, wouldn't trade it for the world!
Oh, tot 10 uur inderdaad. Volgens mij was dat voorheen 16 uur bij licht gebruik.

Ik vind mijn 13" MBP uit 2015 eigenlijk op alle fronten beter. Fijner toetsenbord, geen rare touch bar, geen bizar groot track pad...
Nee hoor. Is nooit 16 uur geweest. De pro's staan bekend om tussen de 5-8 uur te kunnen meegaan. Maarja hier zat dan ook de maximaal mogelijke accucapaciteit in om het legaal te houden (99,5 Wh).

En bizar groot trackpad? Hij mag van mij nog wel groter hoor.
Het hangt echt van het gebruik af. 12u en meer was zeker realistisch bij de 2015 modellen. Anderzijds kan je met een 45watt tdp cpu een 90Kwh batterij in 2 uur leegtrekken.

Bij de nieuwe modellen is de accuduur wellicht iets korter (grootteorde 15-20%) en dat is voor sommigen een teleurstelling. Terwijl de accuduur nog steeds bovengemiddeld/uitstekend is. Bovendien speelt het feit dat wanneer je een nieuwe Mac initialiseert met een paar 100GB bestanden, er de eerste uren/dagen nogal wat in de achtergrond draait, dat is niet gunstig voor de "eerste indruk".
Eens. In het begin zal de batterij flink te voorduren krijgen, maar 12 uur is wel fikse opgave hoor. Ik heb het in ieder geval nooit kunnen halen met die van mij. Nou ligt het er natuurlijk heel erg aan wat je gebruikt en hebt draaien maar dan nog.
Als je Chrome gebruikt dan is het bekend dat je een veel korte accuduur hebt dan met Safari. Op OS X kun je het beste Safari gebruiken en op Windows het beste Edge voor een lange accuduur.
Je moet juist Safari gebruiken als je een stille en zuinige macbook wilt. Chrome verbruikt zoveel resources dat de fan harder moet gaan draaien, en de batterij sneller leeg gaat.
Wat is de reden dat je de MBP niet aan je inventaris hebt toegevoegd?
Ik zie alleen maar een Windows game machine uit 2011 en wensen lijstjes met upgrades daar voor.

De machine kan niet heel oud zijn dus waarom ga je niet terug naar de Apple Store met je klacht?
Omdat ik mijn inventaris al jaren niet heb bijgewerkt. Nu m'n Apple dingen toegevoegd.

Ik ben al bij Apple geweest, die zeggen niets te kunnen doen. Collega's van mij zijn meer aandringend geweest en waren hun laptop een paar weken kwijt. Resultaat: hetzelfde probleem bleef bestaan, ze konden het probleem niet achterhalen. Daar zit ik niet zo op te wachten. Als ik eens in de 2 maanden in een trein zit met mijn laptop bij me is dat maar voor een uurtje of twee. Ik heb niet zoveel aan 10 uur.

Eigenlijk hoop ik op een class-action lawsuit waarna we geld terug krijgen. Zal m'n werkgever vooral blij mee zijn :+
Je moet eens even die app downloaden waarmee je kan zien welke GPU er wordt gebruikt. Sommige applicaties (zoals IDEs) spreken namelijk gelijk de dGPU aan. Maar met een 13" maakt dat niet uit.
Safari? Dat gebruik ik niet eens. En mijn 15" MBP met touch bar haalt nauwelijks 5 uurtjes. Scherm op halve helderheid en verder niets bijzonders. Best waardeloos
Als we dan toch anekdotes gaan posten, ik haal consistent 8+ uur met de 15" MBP, onder lichte load en met de brightness ongeveer op de helft. Wat ik wel heb gemerkt is dat de accuduur hard naar beneden gaat als je processen hebt draaien die continu actief zijn en dus niet idlen, wat op zich natuurlijk niet zo vreemd is gezien het feit dat de accu van de MBP 15" simpelweg niet zo groot is.

Bij normaal gebruik is de accuduur echter vergelijkbaar aan wat ik gewend was van de MBA en de vorige 15" MBP, het lijkt er dus op dat de kleinere accu moet worden gecompenseerd door agressievere power-saving, en als daar iets fout gaat (door bugs, of door processen die niet willen idlen) dan is de accuduur inderdaad niet fantastisch. Je kunt je echter afvragen of een iets grotere accu dan echt zoden aan de dijk had gezet, over het algemeen houdt geen enkele laptop met een niet-ULV CPU het erg lang vol onder load.
Ik heb zo vermoede dat door de kleine accu Apple alle zeilen heeft bijgezet om het OS en de software zo efficiënt mogelijk te laten lopen. Ik kan me daarom ook voorstellen dat als je dezelfde test in chrome zou doen dan zouden de resultaten gemiddeld een stuklager uitkomen.

Een bijkomend nadeel, van een kleine accu is dat alles wat extra draait op de achter of voorgrond meteen extra merkbaar is aan je accu duur. Bij telefoons zie je dit ook, Android lopen sneller leeg door allerlei processen die op de achtergrond werken. Bij iOS draait er bijna niks op de achtergrond om zo energie te besparen.

Hoewel bij telefoons en tablets je er mee wegkomt, vraag ik me af of je dit ook voor laptops zover kunt beperken.
Dat hoef je je niet voor te stellen, dat is al getest; http://www.theverge.com/2...rome-macbook-battery-life bijvoorbeeld. Daar zullen de Chrome devs ook wel aan werken / gewerkt hebben (is een artikel van bijna twee jaar oud), maar toch.
Dit geldt nog steeds. Daarnaast is het gehuegengebruik van chrome de pan ut gerezen. Waar ik met safari rustig 800 tabs open kan hebben heeft chrome met een tab of 50 mijn hele ram vol zitten.
Lijkt plausibel te zijn. Echter verklaart dit naar mijn idee niet de enorme fluctuaties die Consumer reports in hun testen had, ca 19 uur in de beste situatie en ca 3,5 uur in de slechtste situatie..
Dat heb je nou met bugs. Die treden niet altijd op, maar vaak alleen in bepaalde scenario's. Wellicht zelfs op een bepaald tijdstip. Zonder de technische details kun je daar dus niets over zeggen. Echter, het feit dat ze nu wel consistente ervaringen hebben met de accuduur geeft aan dat het probleem is opgelost en dat de enorme fluctuaties wel daardoor verklaart kunnen worden.

Volg het bewijs en niet wat je hoopt dat waar is ("Echter verklaart dit naar mijn idee niet de enorme fluctuaties").
Gelukkig heb ik vooralsnog geen problemen gehad met de accuduur van mijn MacBook Pro 15". Deze is iets beter dan mijn MacBook Pro 13" uit 2014. Ik ben in ieder geval een zeer tevreden gebruiker :*)
Het lijkt me niet dat dit alles verklaart, aangezien ze er gewoon een relatief kleine accu in gegooid hebben. 49.2 Wh voor de touchbar versie, tegenover 54.5 Wh voor de versie zonder touchbar (Fn-key versie). Dus met minder accucapaciteit moet ook nog een extra schermpje en een iets meer verbruikende processor (hogere TDP) aangedreven worden.

Zie voor meer info:
http://www.jeffgeerling.c...016-macbook-pro-touch-bar
https://www.ifixit.com/Te...+Touch+Bar+Teardown/73480
De vraag is waarom de touchbar versie een kleinere Accu heeft want het lijkt er op dat er wel degelijk plaats is voor een 54.5 Wh versie omdat er simpelweg meer 'verpakking' is bij de 49.2 Wh versie.

Vergelijk 49.2 Wh VS 54.5Wh

Kon de productie niet volgen? Het is mogelijk uit de lucht gegrepen maar de lijkt de kleine accu in de 49.2 Wh touchbar versie verdacht veel op die van de Iphone 7/plus. Waarbij de batterij van de 7plus iets breder is de gewone Iphone. Als de batterij van de touch-bar versie ziet lijkt het wel een Iphone7 + Ipone7plus batterij te zijn, naasr elkaar dan.

En de batterij van de Ipad Pro 9.7" heeft dan weer veel weg van Mac pro 2016. Let op dit is maar een insteek die mogelijk uit de luchtgegrepen is maar het viel me wel op.

De Ipad po staat op 14 Whr per unit met 27,91 Whr in totaal. De Mac pro lijkt er 3 te hebben maar dan zou het totaal maar op +- 42Whr uitkomen. Het is dus maar bij benadering gelijk.

Aangezien elke Whr meegenomen is snap ik echt niet waarom Apple zonder duidelijke reden 5Whr van de touchbar versie afpitst.

[Reactie gewijzigd door Coolstart op 11 januari 2017 18:36]

Volgens mij had Apple er voor gekozen om een oudere accu er in te doen omdat deze nieuwe (beloofde) niet door tests heen kwam: https://www.iphoned.nl/nieuws/2016-macbook-pro-accutest/
Aanvankelijk zou Apple van plan zijn geweest om een nieuwe accu in de MacBook Pro te stoppen die precies gevormd was naar de binnenkant van de laptop. Na het falen van een test werd echter besloten om een oudere batterij in te bouwen, zodat de feestdagen niet gemist zouden worden.
Dat kan die ruimte wellicht verklaren?
Het vreemde van de tests van CR is dat de batterijduur fluctueert van een paar uur tot >15 uur onder, zeggen zij, exact dezelfde toestellen. Dan klopt er echt iets niet aan je testmethode.
Het vreemde van de tests van CR is dat de batterijduur fluctueert van een paar uur tot >15 uur onder, zeggen zij, exact dezelfde toestellen. Dan klopt er echt iets niet aan je testmethode.
Zelfs wanneer Apple het probleem heeft erkend en werkt aan een oplossing de fout bij de test methode neerleggen 8)7
[...]


Zelfs wanneer Apple het probleem heeft erkend en werkt aan een oplossing de fout bij de test methode neerleggen 8)7
TMC heeft wel een punt, Apple erkent dat er een bug is die inderdaad de accuduur verkort wanneer er gebruik wordt gemaakt van een bepaalde setting maar een computer is over het algemeen behoorlijk deterministisch. Wanneer iemand dus consistent dezelfde test uit blijft voeren is het raar dat je zo een grote marge krijgt.

Aangezien we niet de exact details van de bug (en de tests) weten blijft het natuurlijk giswerk over wat voor een exact bijdrage deze leveren maar het kan best een EN / EN verhaal zijn waarbij beide een rol gespeeld hebben.
Ligt er natuurlijk maar net aan wat de bug is. Het kenmerk van een bug is nou juist dat hij optreedt bij een onverwachte samenloop van omstandigheden. Dus om maar een dwarsstraat te noemen blijft een systeemproces(wat op gezette tijden start) lang draaien als op het moment dat hij start het geheugen boven een bepaalde waarde zit én de cache setting op de genoemde waarde staat. Wat in dit geval inconsistente resultaten zou kunnen geven omdat de test waarschijnlijk niet op exact dezelfde tijd wordt gestart.
Consumer report is niet bepaald amateuristisch. Bovendien hebben ze dit dus al honderden keren uitgevoerd en is dit de eerste laptop die een dergelijke spreiding vertoont. Hoewel je zou zeggen dat het allemaal deterministisch zou moeten zijn is dat natuurlijk verre van het geval en ook tweakers.net presenteert altijd gemiddeldes. Een EN/EN te concluderen uit een enkele test die bizarre resultaten vertoont na jaren aan consistent resultaten is gewoon onterecht. Zeker als je weet dat er iemand de bestaande software fout heeft onderkent.

[Reactie gewijzigd door Darkstriker op 11 januari 2017 08:42]

Niet bepaald amateuristisch?
Consumer Reports schakelt via een verborgen instelling namelijk de cachingfunctie uit bij zijn browsertest. Hierna kan de organisatie herhaaldelijk dezelfde webpagina laden zonder dat deze uit de cache gehaald wordt, wat een betere nabootsing is van echte gebruiksomstandigheden.
Met zulke uitspraken ga ik daar toch behoorlijk aan twijfelen. Het idee van cache is juist dat dezelfde pagina voor een aantal gevallen cq binnen X tijd niet opnieuw hoeft worden opgehaald.

Je test is dan dus niet realistisch genoeg omdat je anders geen functies hoeft uit te schakelen waarvan ze zelf zeggen dat de meeste gebruikers dit niet doen. Lijkt mij niet helemaal te kloppen dan.
Ze willen juist testen hoedat nieuwe pagina's inladen en hoe dit op de batterij reflecteert.

Zolang als ze consistent hetzelfde doen bij alles wat ze testen is er niks aan de hand. Je wil immers testen met gelijke settings. De bedoeling is immer niet "testen of we deze pagina een miljoen keer kunnen laden" . Maar "hoe lang blijft de batterij meegaan als we surfen" .
Dat snap ik, maar dit als argument gebruiken omdat het realistischer is, is natuurlijk kul. De cache is er namelijk niet alleen voor de inhoud van pagina's maar ook scripts. En laat vrijwel iedere site tegenwoordig gebruik maken van een vrij grote set met google trackers en andere advertentie dingen, maar ook simpele libraries als Jquery en node.js. Deze libs worden nu ook continu ververst terwijl deze juist veel sneller uit de cache getrokken kunnen worden.
Het is realistischer nogmaals je wil een vergelijk maken en een benadering geven van wat realistisch is.

Ze waren niet de enige die problemen hadden met de batterij :

http://uk.businessinsider...xpected-2016-11?r=US&IR=T

Wat betekend dat die ofwel op dezelfde manier testen (onwaarschijnlijk) of dat in gewoon gebruik dit probleem naar boven kwam.
Het maakt dat de test vanuit het perspectief van CPU gebruik en geheugen gebruik een stuk realistischer is dan wanneer men continue dezelfde pagina zou gaan laden vanuit die cache. Bij benchmarking heb je een geijkte testmethode nodig. Lukraak een gebruiker gebruik laten maken van een apparaat is geen geijkte methode en zal daarom niet werken. Men doet dus aanpassingen om het resultaat dichter bij de werkelijkheid te brengen.
Nee maar continu dezelfde pagina opvragen heeft niks te maken met realistisch gebruik. Ik weet niet welke pagina het is maar stel dat fabrikanten dit wel weten en hierop de software aanpassen? Dergelijke dingen zijn ook gebeurd met benchmarks op android toestellen. Dan thermal limits werden dan naar boven bijgesteld zodat het apparaat langer zijn cpu turbo kon vasthouden.

Enfin. Deze methode heeft meer weg van een statische bench dan daadwerkelijk realistische resultaten. Het zou beter zijn als ze een interne lijst met websites zouden hosten en dan wel de af fabriek instellingen gebruiken.
Het is realistischer nogmaals je wil een vergelijk maken en een benadering geven van wat realistisch is.

Ze waren niet de enige die problemen hadden met de batterij :

http://uk.businessinsider...xpected-2016-11?r=US&IR=T

Wat betekend dat die ofwel op dezelfde manier testen (onwaarschijnlijk) of dat in gewoon gebruik dit probleem naar boven kwam.

Er is niks mis met deze benchmark die ze voor alle laptops gebruiken. Apple had een issue en het is volgens apple nu opgelost.
Sorry, maar als je test er van uit gaat dat er een aantal opties uitgeschakeld kunnen worden dan is dit niet realistisch. Voor de vergelijking is het wel eerlijk om dit bij allemaal te doen, maar of het reel is is een ander verhaal. Zo blijven alle scripts die tweakers inlaad bij mij gewoon in cache staan en hoeven deze niet met iedere page opnieuw worden opgehaald. Kijkend in mijn webinfovenster is dat ongeveer de helft van het verkeer.

Het gaat om 11 CSS bestanden, 12 Javascript files, ontzettend veel images voor logo's en smileys en vrijwel geen statische HTML pagina's die verplicht iedere keer opgehaald moeten worden. Alle reacties en het verversen daarvan gaat dynamisch door scripts. Het uitschakelen van de cache is totaal niet relevant voor webpagina's met content als dit.

Tegenwoordig werkt men met MVC applicaties. Je hebt een model, view en controller. De view en controller worden eenmalig ingeladen en vervolgens uit cache getrokken terwijl het Model dmv "binding" is gekoppeld aan de view. Veranderd het model (de ruwe data) dan veranderd de view. Controller en View zijn echter de grootste boosdoeners aangezien die alle complexe logica bevatten. Het kan hier rustig om een miljoen regels code gaan voor grote applicaties. Het uitschakelen van de cache zorgt ervoor dat dit dus iedere keer weer wordt binnengehaald en dat is naast erg traag ook nog eens een gruwelijke energie slurper.

Als ik een half uurtje op tweakers zit rond te struinen kan cache me meer dan 90% van de opgevraagde data schelen en dat is een realistisch scenario. Daarom hebben we cache en werken we met MVC. Dat is nou eenmaal veel efficiënter voor beide partijen (minder netwerkverkeer en dus ook minder verwerking en minder laadtijd).

De gebruikte methode is dus vergelijkbaar met een statische benchmark aangezien de methode vrij onrealistisch is. Ik ga niet om de zoveel seconden exact dezelfde pagina opvragen met cache uitgeschakeld en dat dan 10 uur lang. Maak dan een realistische methode voor gesimuleerd webbrowsen. Dat kan namelijk makkelijk. Voor de vergelijking is het goed dat je een standaard procedure hebt, maar voor het realisme is deze methode totaal niet geschikt. Tweakers gebruikt volgens mij ook een hele andere testmethode voor browsing. Die hebben een waslijst met websites die ze bezoeken. Ook deze test gaf problemen met safari (crashte uiteindelijk), maar is wel een stuk realistischer omdat deze ook daadwerkelijk heen en weer scrolled zoals een geïnteresseerde lezer dat zou doen.
Voor de vergelijking is het wel eerlijk om dit bij allemaal te doen
En daar ging het vooral over. Het geeft een goede schatting om te vergelijken en zien of de laptop goed omgaat met surfen.

Je kan nooit iets realistisch maken want iedereen heeft een ander patroon bezoekt andere websites en dus zal langer of korter met een batterij kunnen meegaan.

En nogmaals : ze waren niet de enige die opmerkte dat er iets wat met het verbruik hierbij. Het probleem lag bij de laptop niet bij de test. Dit doet me denken aan de bekende "you are holding it wrong"
Nee tuurlijk niet.

Maar cache uitschakelen om het realistischer te maken is klinkklare onzin.
Men laad steeds dezelfde pagina in . de cache word uitgeschakeld om te simuleren naar steeds verschillende webpaginas te gaan. In dat opzicht maakt dat het realistischer de meeste mensen surfen immers naar andere webpaginas en refreshen niet dezelfde 100000 keer
Ja maar zoals ik dus al aangaf is dat nog steeds niet realistisch aangezien een scriptlibrary van bijvoorbeeld Jquery dan alsnog uit de cache wordt getrokken. Van vrijwel alle CDN gehoste libraries heb je een kopie in het cache geheugen staan waardoor ook page visits naar nieuwe sites minder verkeer opleveren.

En dan nog steeds zijn er vaak websites zoals fora als dit die tig keer geladen worden op een dag.

Als zelfs tweakers gewoon een test heeft die daadwerkelijk het browse gedrag nabootst (inclusief heen en weer scrollen en wat linkjes doorklikken), vraag ik mij toch af of deze mensen niet ook eens moeten gaan kijken naar een update van de testmethodiek.
Je blijft afgeven op de test waar geen probleem mee was, integendeel het ontdekte een effectief probleem met de laptop dat nu gecorrigeerd is .

Elke test is maar een benadering van de realiteit.
. Een EN/EN te concluderen uit een enkele test die bizarre resultaten vertoont na jaren aan consistent resultaten is gewoon onterecht.
Ik trek dan ook nergens deze conclusie, ik stel alleen dat de mogelijk bestaat en doe verder geen uitspraken over de waarschijnlijkheid ervan. Dit mede (zoals ik eerder ook al aangaf) doordat we totaal geen informatie hebben over zowel de bug als de tests.
Aangezien we niet de exact details van de bug (en de tests) weten blijft het natuurlijk giswerk over wat voor een exact bijdrage deze leveren
Daar moet je zin stoppen :)

De rest is namelijk in de categorie: "It's a flying object. I don't know what it is, so it must be aliens." Nee, je weet niet wat is, dus einde zin. En ze leefden nog lang en gelukkig.

[Reactie gewijzigd door LarBor op 11 januari 2017 10:48]

[...]


Daar moet je zin stoppen :)

De rest is namelijk in de categorie: "It's a flying object. I don't know what it is, so it must be aliens." Nee, je weet niet wat is, dus einde zin. En ze leefden nog lang en gelukkig.
Nee, wat ik doe heet speculatie over mogelijke oorzaken. De vergelijking die jij geeft neemt iets als een gegeven en gaat uit van aannames. Twee verschillende concepten.
maar het kan best een EN / EN verhaal zijn waarbij beide een rol gespeeld hebben.
kan is hier een vervoeging van het werkwoord kunnen wat volgens de Nederlandse taal gebruikt kan worden om een mogelijkheid uit te drukken. Er is dus niets mis met mijn de betekenis van de eerder genoemde zin. Een beter vergelijk is dus:
"It's a flying object. I don't know what it is, it might be aliens but it could be anything else."
Het is gewoonweg bizar, dat je bij éénzelfde test verschillen krijgt van de grootteorde 3.5 tot 19u... Als je dat soort bizarre resultaten krijgt, zonder enige verklaring daarvoor, dan moet je je idd ook vragen stellen over de tests zelf.
Of het ligt gewoon aan de Apple. Ik weet dat dit in jouw ogen volstrekt onmogelijk is, maar de nieuwe MacBook Pro was de eerste van de 140 laptops die dit gedrag liet zien.

En hoe ik het begreep, had CR dus ook tests gedaan zonder gebruik te maken van de verborgen instelling. Wellicht verklaarde dat de >10 uur in sommige tests.
Niet echt, je krijgt bij een telefoon toch ook de standby time wat vaak een week of meer is, terwijl bij actief gebruik de gemiddelde smartphone het amper een dag uithoud ? De vraag is hoe relevant die waarden zijn voor de gemiddelde consument, maar daar gaat het artikel niet dieper op in... :)
Word ik bij het vorige artikel voor gek uitgemaakt dat de MacBooks problemen hebben met de accuduur. En nu brengt Apple een patch uit.

Hopelijk komt de batterijtijdsindicatie ook terug, ik gebruik dit altijd om te kijken of ik het eind van de dag nog trek met de programma's die ik open heb staan.
Het rare was dat niemand de resultaten van CR kon reproduceren.
Wellicht was de test die CR gebruikte dan raar?
Zolang CR de testprocedure niet vrijgeeft is het gissen. De accuduur van een Macbook kan echt goed zijn, maar als je geen Safari etc gebruikt dan gaat de accuduur rap omlaag.
Volgens mij heb je sowieso niet zoveel aan een indicatie hoelang de acculading nog meegaat. Ik neem aan dat bij zware toepassingen de accu sneller leeg raakt. Geen enkele indicator kan voorspellen welke toepassing je straks gaat gebruiken.
Aan b.v. de tijdsaanduiding in W10 hecht ik om die reden dan ook niet veel waarde.
(net 2 uur Parallels gebruikt, ik denk dat het dan sneller gaat dan 2 uur Patience spelen ;) )
Jij hebt er mogelijk niks aan, ik wel. Zoals ik in mijn reactie ook aangeef is het een goeie tijdsindicatie om te kijken of je je werkdag nog doorkomt met de applicaties die je open hebt staan.

Ik kan niet altijd mijn Macbook laden, als ik dan nog even moet kijk ik welke apps er veel verbruiken en sluit ik die af. Daarna kon je dan opnieuw de indicatie bekijken om te controleren of je nu wel de dag af kon maken.
neem aan dat het een algemene macOS update betreft...
Jep, nu alleen als béta nog. Give it a week or 2.
Geen last gehad van snelle battery drain. Wel gemerkt, maar geen last. Heel de dag werk ik toch op een thunderbolt display met de stekker in het stopcontact. 's Avonds ging hij wel snel leeg op de bank, maar ik moet ook een keertje naar bed en 's ochtends gaat hij gewoon weer aan de lader.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True