OnePlus og Meizu har blitt tatt for å jukse på benchmarks. XDA undersøker hvordan det skjedde, og hva som kan gjøres for å forhindre at det skjer igjen.
For noen år siden ble det et betydelig oppstyr, da mange store produsenter ble tatt for å jukse med benchmarks. OEM-er i alle størrelser (inkludert Samsung, HTC, Sony, og LG) deltok i dette våpenkappløpet for å forsøke å lure brukere uten å bli tatt, men heldigvis stoppet de til slutt sin benchmark-juks etter noen ærlige diskusjoner med bransjeeksperter og journalister.
Tilbake i 2013 var det oppdaget at Samsung kunstig økte GPU-klokkehastighetene i visse applikasjoner, noe som utløste en rekke undersøkelser inn i benchmark-juks på tvers av hele spekteret av produsenter. På det tidspunktet fant undersøkelsen at nesten alle produsenter bortsett fra Google/Motorola drev med benchmark-juks. De investerte alle tid og penger i forsøk på å få litt ekstra ytelse ut av telefonene sine i benchmarks, på måter som ville ikke ha noen positiv effekt på daglig bruk, i et forsøk på å lure brukere til å tro at telefonene deres var raskere enn de faktisk var. Disse utviklingsarbeidet løp gjennom hele spekteret, fra å sette gulv for klokkehastighet, til å tvinge klokkehastighetene til maksimale innstillinger, til å til og med lage spesielle høyere effekttilstander og spesielle klokkehastigheter som bare var tilgjengelige ved benchmarking, med disse anstrengelsene som ofte resulterte i bare et par prosentpoeng økning i benchmark.
Det var betydelig forargelse da det ble oppdaget, ettersom disse forsøkene på benchmark-juks stred mot selve poenget med selve benchmarkene. De fleste benchmarks er ikke der for å fortelle deg den teoretiske maksimale ytelsen til en telefon under laboratorieforhold som ikke er det reproduserbare i daglig bruk, men snarere er de der for å gi deg et referansepunkt for sammenligninger i den virkelige verden mellom telefoner. Etter litt offentlig roping (og noen private samtaler) fra teknologipublikasjoner, industriledere og allmennheten fikk de fleste produsenter beskjeden om at benchmark-juks rett og slett ikke var akseptabelt, og stoppet som en resultat. De fleste av de få som ikke stoppet på det tidspunktet stoppet like etter, siden det ble gjort betydelige endringer til hvor mange benchmarks som kjøres, i et forsøk på å motvirke benchmark-juks (ved å redusere fordelen fra den). Mange benchmarks ble gjort lengre slik at den termiske strupingen fra å maksimere klokkehastighetene umiddelbart skulle bli tydelig.
Når vi intervjuet John Poole, skaperen av Geekbench, temaet benchmark-juks og hva selskaper som Primate Labs kan gjøre for å forhindre at det dukket opp. Spesielt Primate Labs gjorde Geekbench 4 ganske mye lengre enn Geekbench 3, delvis for å redusere effekten av benchmark-juks. Redusere fordelene for å sikre at utviklingen kostnadene ved benchmark-juks er ikke verdt det.
"Problemet er at når vi har disse store kjøretidene hvis du begynner å spille ting ved å øke klokken hastigheter eller deaktivering av regulatorer eller noe sånt, vil du begynne å sette reell fare i telefon... Hvis du skal spille det... du får ikke så mye ut av det. Du kan fortsatt få et par prosent, men er det virkelig verdt det?" - John Poole
Hva skjedde
Dessverre må vi rapportere at noen OEM-er har begynt å jukse igjen, noe som betyr at vi bør være på utkikk igjen. Heldigvis har produsenter blitt stadig mer lydhøre for problemer som dette, og med riktig oppmerksomhet kan dette løses raskt. Det er litt sjokkerende å se produsenter implementere benchmark-juks i lys av hvor ille tilbakeslaget var forrige gang det ble forsøkt (med noen benchmarks som fullstendig ekskluderte jukseenheter fra ytelsen lister). Med det tilbakeslaget i kontrast til hvor liten ytelsesgevinsten fra benchmark-juks vanligvis er (med de fleste av forsøkene som resulterte i mindre enn 5 % poengøkning forrige gang), hadde vi virkelig håpet at alt dette ville ligge bak oss.
Tidspunktet for dette forsøket er spesielt uhensiktsmessig, ettersom for et par måneder siden benchmark-juks forlot verden som et rent entusiastbekymring, og gikk inn i den offentlige sfæren da Volkswagen og Fiat Chrysler begge ble tatt for å jukse med utslippene sine benchmarks. Begge selskapene implementerte programvare for å oppdage når dieselbilene deres ble satt gjennom utslippstesting, og fikk dem til å bytte til en lavutslippsmodus som så drivstofføkonomien deres falle, i et forsøk på å konkurrere med bensinbiler i drivstoffeffektivitet mens de fortsatt holdt seg innenfor regulatoriske grenser for utslipp tester. Så langt har skandalen resultert i milliarder i bøter, titalls milliarder av tilbakekallingskostnader og siktelser – absolutt ikke den typen gjengjeldelse OEM-er vil noen gang se for å blåse opp sine benchmark-score, som kun er for brukersammenligninger og ikke brukes til å måle noen regulatoriske krav.
Samtidig som undersøker hvordan Qualcomm oppnår raskere appåpningshastigheter på den da nye Qualcomm Snapdragon 821 la vi merke til noe merkelig på OnePlus 3T at vi ikke kunne reprodusere på Xiaomi Mi Note 2 eller Google Pixel XL, blant andre Snapdragon 821-enheter. Sjefredaktøren vår, Mario Serrafero, brukte Qualcomm Trepn og Snapdragon Performance Visualizer for å overvåke hvordan Qualcomm "øker" CPU-en klokkehastighet ved åpning av apper, og la merke til at enkelte apper på OnePlus 3T ikke falt tilbake til normale tomgangshastigheter etter åpning. Som en generell tommelfingerregel unngår vi å teste benchmarks med ytelsesovervåkingsverktøy åpne når det er mulig på grunn av den ekstra ytelseskostnaden de medfører (spesielt på enheter som ikke er Snapdragon der de ikke er offisielle skrivebordsverktøy), men i denne hendelsen hjalp de oss med å legge merke til en merkelig oppførsel som vi sannsynligvis ville ha gått glipp av ellers.
Når du går inn i visse benchmarking-apper, ville OnePlus 3Ts kjerner holde seg over 0,98 GHz for de små kjernene og 1,29 GHz for de store kjernene, selv når CPU-belastningen falt til 0 %. Dette er ganske merkelig, siden begge settene med kjerner normalt faller ned til 0,31 GHz på OnePlus 3T når det ikke er noen belastning. Da vi først så dette, var vi bekymret for at OnePlus' CPU-skalering rett og slett ble satt litt merkelig, Men etter ytterligere testing kom vi til den konklusjonen at OnePlus må være målrettet applikasjoner. Vår hypotese var at OnePlus målrettet disse referansene etter navn, og gikk inn i en alternativ CPU-skaleringsmodus for å pumpe opp referanseresultatene deres. En av våre hovedbekymringer var at OnePlus muligens satte løsere termiske begrensninger i denne modusen for å unngå problemene de hadde med OnePlus One, OnePlus X og OnePlus 2, der telefonene håndterer de ekstra kjernene som kom på nettet for flerkjernedelen av Geekbench dårlig, og av og til strupes betydelig ned som et resultat (til det punktet hvor OnePlus X noen ganger scoret lavere i flerkjernedelen enn i singelen kjernedelen). Du kan finne kraftig struping i vår OnePlus 2 anmeldelse, der vi fant ut at enheten kunne miste opptil 50 % av Geekbench 3 flerkjernepoengsummen. Senere, da vi begynte å sammenligne struping og termikk på tvers av enheter, ble OnePlus 2 ble et lærebokeksempel på hva OEM-er bør unngå.
Vi tok kontakt med teamet kl Primate Labs (skaperne av Geekbench), som var medvirkende til å avsløre den første bølgen av benchmark-juks, og samarbeidet med dem for videre testing. Vi tok med en OnePlus 3T til Primate Labs kontor i Toronto for en innledende analyse. Den første testen inkluderte en ROM-dump som fant ut at OnePlus 3T var direkte på utkikk etter ganske mange apper ved navn. Mest bemerkelsesverdig var OnePlus 3T på jakt etter Geekbench, AnTuTu, Androbench, Quadrant, Vellamo og GFXBench. Siden vi på dette tidspunktet hadde ganske klare bevis på at OnePlus drev med benchmark-juks, bygde Primate Labs en "Bobs minigolfputt" versjon av Geekbench 4 for oss. Takk til vesentlige endringer mellom Geekbench 3 og 4, den "Minigolf" versjonen måtte bygges om fra grunnen spesifikt for denne testingen. Denne versjonen av Geekbench 4 er designet for å unngå benchmark-deteksjon, for å la Geekbench kjøre som normalt applikasjon på telefoner som jukser (som går utover pakkenavnet som lurer de fleste forsøk på benchmarking juks).
Et overraskende eksempel
Umiddelbart etter åpning av appen var forskjellen tydelig. OnePlus 3T gikk på tomgang på 0,31 GHz, slik den gjør i de fleste apper, i stedet for på 1,29 GHz for de store kjernene og 0,98 GHz for de små kjernene, slik den gjør i den vanlige Geekbench-appen. OnePlus gjorde den CPU-guvernøren mer aggressiv, noe som resulterte i et praktisk kunstig klokkehastighetsgulv i Geekbench som ikke var der i den skjulte Geekbench-konstruksjonen. Det var ikke basert på CPU-arbeidsbelastningen, men snarere på appens pakkenavn, som den skjulte konstruksjonen kunne lure. Mens forskjellen i individuelle kjøringer var minimal, skinner de termiske gassavslapningene i vår vedvarende ytelsestest, vist nedenfor.
Fra vår testing ser det ut til at dette har vært en "funksjon" i Hydrogen OS en god stund nå, og ble ikke lagt til Oxygen OS før fellesskapet bygges opp før Nougat-utgivelsen (etter to ROM-er ble slått sammen). Det er litt skuffende å se, spesielt i lys av programvareproblemene som OnePlus har hatt denne måneden etter sammenslåingen av ROM-ene, fra bootloader-sårbarheter til GPL-samsvarsproblemer. Vi håper at når støvet legger seg etter sammenslåingen av de to lagene, vil OnePlus komme tilbake til form og fortsette å posisjonere seg som et utviklervennlig alternativ.
Med "Minigolf" versjonen av Geekbench i hånden, gikk vi ut og begynte å teste andre telefoner for benchmark-juks også. Heldigvis viser testingen vår ingen juks fra selskapene som var involvert i skandalen for et halvt tiår siden. HTC, Xiaomi, Huawei, Honor, Google, Sony og andre ser ut til å ha konsekvente resultater mellom den vanlige Geekbench-byggingen og "Minigolf" bygge på våre testenheter.
Dessverre fant vi mulige bevis på benchmark-juks som vi ennå ikke har kunnet bekrefte fra et par andre selskaper, som vi vil undersøke nærmere. Det aller verste eksemplet på dette var i den Exynos 8890-drevne Meizu Pro 6 Plus, som tok benchmark-jukset til en annen ytterlighet.
Et forferdelig eksempel
Meizu har historisk sett sin CPU-skalering ekstremt konservativt. Spesielt setter de ofte telefonene opp slik at de store kjernene sjelden kommer online, selv når de er i "ytelsesmodus", noe som gjør flaggskipprosessorene (som de utmerkede Exynos 8890) som de legger inn i flaggskiptelefonene sine, fungerer som mellomtoneprosessorer. Dette kom på hodet i fjor da Anandtech kalte Meizu ut for deres dårlige ytelse på Anandtechs JavaScript-standarder på Mediatek Helio X25-baserte Meizu Pro 6, og bemerket at de store kjernene forble offline i det meste av testen (når testen skulle ha kjørt nesten utelukkende på den store kjerner). Anandtech la merke til forrige uke at en programvareoppdatering var blitt skjøvet til Meizu Pro 6 som endelig tillot Meizu å bruke disse kjernene til det fulle. Anandtechs smarttelefon seniorredaktør, Matt Humrick, bemerket at "Etter oppdatering til Flyme OS 5.2.5.0G, yter PRO 6 betydelig bedre. Kraken-, WebXPRT 2015- og JetStream-resultatene forbedres med omtrent 2x-2,5x. Meizu justerte tilsynelatende belastningsterskelverdien, slik at tråder kunne migrere til A72-kjernene oftere for bedre ytelse."
Dessverre ser det ut til at i stedet for å forbedre CPU-skaleringen for deres nye enheter for å få bedre benchmark-score, ser de ut til å ha satt telefonen til å bytte til å bruke de store kjernene når visse apper er det løping.
Når du åpner en benchmarking-app, anbefaler vår Meizu Pro 6 Plus at du bytter til "Performance Mode" (som alene er nok til å bekrefte at de leter etter spesifikke pakkenavn), og det ser ut til å utgjøre en betydelig forskjell. Når den er i standard "Balansemodus", scorer telefonen konsekvent rundt 604 og 2220 på Geekbenchs enkeltkjerne- og flerkjerneseksjoner, men i "Performance Mode" den får 1473 og 3906, hovedsakelig takket være de store kjernene som forblir av for det meste av testen i "Balance Mode", og slår seg på i "Ytelsemodus". Meizu ser ut til å låse de små kjernene til maksimal hastighet på 1,48 GHz, og sette et hardt gulv for to av de store kjernene deres på 1,46 GHz når de kjører Geekbench mens du er i "Performance Mode" (med de to andre store kjernene som får skalere fritt og ganske aggressivt), som vi ikke ser når kjører "Minigolf" bygge.
Selv om det kan være en fin funksjon å kunne velge mellom en høyeffektmodus og en laveffektmodus, ser det i dette tilfellet ut til å være noe mer enn et salongtriks. Meizu Pro 6 Plus ser anstendige resultater i "Performance Mode" for den vanlige Geekbench-appen, men når du bruker "Minigolf" bygget av Geekbench, faller den rett tilbake på samme ytelsesnivå som den har når den er satt til "Balansemodus". Den høyere ytelsestilstanden på Meizu Pro 6 Plus er kun for benchmarking, ikke for faktisk daglig bruk.
En ting å merke seg er at da vi testet Meizu Pro 6 Plus i "Performance Mode" med hemmeligheten bygget av Geekbench, kom de store kjernene online hvis vi registrerte klokkehastighetene med Qualcomm Trepn. Vi har ennå ikke bestemt om Meizu'en gjenkjenner at Trepn kjører og slår på de store kjernene i del på grunn av det, eller hvis det rett og slett slår på de store kjernene på grunn av den ekstra CPU-belastningen som det skaper. Selv om det kan høres kontraintuitivt ut at en ekstra belastning i bakgrunnen (for eksempel når vi holdt ytelsesgrafer på under testen) ville øke resultatene av en benchmark, kan Meizus konservative skalering bety at den ekstra overhead var nok til å skyve den over kanten, og kalle de store kjernene til handling, og dermed forbedre ytelsen for alle oppgaver.
Når mottakelige OEM-er gir tilbakemelding...
Etter vår testing kontaktet vi OnePlus om problemene vi fant. Som svar, OnePlus lovet raskt å slutte å målrette mot benchmarking-apper med deres benchmark-juks, men har fortsatt til hensikt å beholde det for spill (som også blir benchmarked). I en fremtidig versjon av OxygenOS vil ikke denne mekanismen bli utløst av benchmarks. OnePlus har vært mottakelig for vårt forslag om å legge til en bryter også, slik at brukerne vet hva som skjer under panseret, og i det minste burde den urettferdige og misvisende fordelen i benchmarks være rettet opp. På grunn av den kinesiske nyttårsferien og funksjonsetterslepet kan det imidlertid ta en stund før vi ser brukervendte tilpasningsalternativer for denne ytelsesfunksjonen. Selv om det å korrigere atferden alene er en forbedring, er det fortsatt litt skuffende å se regelmessig applikasjoner (som spill), siden det er en krykke å målrette mot spesifikke apper, i stedet for å forbedre den faktiske ytelsen skalering. Ved kunstig å øke aggressiviteten til prosessoren, og dermed klokkehastighetene for spesifikke apper i stedet for å forbedre telefonens evne til å identifisere når den faktisk trenger høyere klokkehastigheter, skaper OnePlus inkonsekvent ytelse for telefonene deres, noe som bare vil bli tydeligere etter hvert som telefonen blir eldre og flere spill som OnePlus ikke har målrettet mot er løslatt. Imidlertid lar implementeringen for øyeblikket spill prestere bedre. OnePlus ga også en uttalelse for denne artikkelen, som du kan lese nedenfor:
«For å gi brukerne en bedre brukeropplevelse i ressurskrevende apper og spill, spesielt grafisk intensive vi implementerte visse mekanismer i fellesskapet og Nougat-bygg for å trigge prosessoren til å kjøre mer aggressivt. Utløserprosessen for benchmarking av apper vil ikke være til stede i kommende OxygenOS-bygg på OnePlus 3 og OnePlus 3T.'
Vi er glade for å høre at OnePlus vil fjerne referansejukset fra telefonene deres. Fremover vil vi fortsette å forsøke å presse OEM-er til å være mer forbrukervennlige når det er mulig, og vi vil holde øye med fremtidig benchmark-juks.
Dessverre er det eneste virkelige svaret på denne typen bedrageri konstant årvåkenhet. Som smarttelefonentusiastsamfunnet må vi holde øynene ute for forsøk på å lure brukere som dette. Det er ikke selve benchmark-skårene vi er interessert i, men snarere hva benchmarkene sier om telefonens ytelse. Mens benchmark-jukset ennå ikke var aktivt på OnePlus 3 når vi vurderte det, var en enkel programvareoppdatering nok til å legge til denne villedende "funksjonen", og illustrerer tydelig at det ikke er tilfelle å sjekke enhetene for benchmark-juks ved første lansering nok. Problemer som dette kan legges til dager, uker, måneder eller til og med år etter at enheten lanseres, kunstig blåser opp de globale gjennomsnittene samlet av benchmarks måneder senere, og påvirker den endelige databasen resultat. Det skal bemerkes at selv med disse justeringene som produsentene måtte investere tid og penger for å utvikle, vi ser vanligvis bare et par prosentpoeng økning i benchmarkscore (unntatt et par utkantsaker som Meizu, der jukset dekker over mye større problemer). Et par prosentpoeng, som er mye mindre enn gapet mellom enhetene med best ytelse og dårligst ytelse. Vi vil imidlertid hevde at med enheter som kjører stadig mer lik maskinvare, kan de ekstra prosentpoengene være den avgjørende faktoren i rangeringslistene som brukere til slutt slår opp. Bedre driveroptimalisering og smartere CPU-skalering kan ha en helt enorm effekt på enhetens ytelse, med forskjellen mellom poengsummen til den beste Qualcomm Snapdragon 820-baserte enheten og den dårligste ytelsen (fra en større OEM) over 20 % på Geekbench. 20 prosent fra driveroptimalisering, i stedet for et par prosentpoeng fra å bruke tid og penger på å lure brukerne dine. Og det er bare snakk om utviklingsinnsatsen som kan påvirke benchmarkscore. Mange av de største fordelene ved å investere i å forbedre en enhets programvare ikke alltid vises på benchmarks, med OnePlus som tilbyr utmerket ytelse i den virkelige verden på enhetene deres. Det burde virkelig være klart hvor et selskaps utviklingsinnsats bør fokuseres i dette tilfellet. Vi når ut til flere selskaper som jukser med benchmarks etter hvert som vi finner dem, og vi håper de er like mottakelige som OnePlus.
Vi vil takke teamet ved Primate Labs nok en gang for å samarbeide med oss for å avdekke dette problemet. Det ville vært vesentlig vanskeligere å teste for Benchmark Cheating uten "Mini Golf"-utgaven av Geekbench.