OnePlus og Meizu er blevet taget i at snyde med benchmarks. XDA undersøger, hvordan det skete, og hvad der kan gøres for at forhindre, at det sker igen.
For et par år siden var der et stort tumult, da adskillige store producenter blev taget i at snyde med benchmarks. OEM'er i alle størrelser (inklusive Samsung, HTC, Sony, og LG) deltog i dette våbenkapløb om at forsøge at narre brugere uden at blive fanget, men heldigvis stoppede de til sidst deres benchmark-snyd efter nogle ærlige diskussioner med brancheeksperter og journalister.
Tilbage i 2013 var det opdaget at Samsung kunstigt øgede sine GPU-urhastigheder i visse applikationer, hvilket udløste en række undersøgelser ind i benchmarksnyd på tværs af hele rækken af producenter. På det tidspunkt viste undersøgelsen, at næsten alle producenter undtagen Google/Motorola var involveret i benchmark-snyd. De investerede alle tid og penge i forsøg på at få en lille smule ekstra ydeevne ud af deres telefoner i benchmarks på måder, som ville ikke have nogen positiv effekt på daglig brug, i et forsøg på at narre brugere til at tro, at deres telefoner var hurtigere end de faktisk var. Disse udviklingsbestræbelser kørte hele spektret, fra indstilling af gulve for urhastigheder, til at tvinge urhastighederne til deres maksimale indstillinger, til endda at skabe særlige højere effekttilstande og specielle clockhastigheder, der kun var tilgængelige ved benchmarking, hvor disse bestræbelser ofte resulterede i blot et par procentpoints stigninger i benchmark.
Der var stor forargelse, da det blev opdaget, da disse forsøg på benchmark-snyd var i modstrid med selve punktet i selve benchmarks. De fleste benchmarks er ikke der for at fortælle dig den teoretiske maksimale ydeevne af en telefon under laboratorieforhold, der ikke er reproducerbare i daglig brug, men snarere er de der for at give dig et referencepunkt for sammenligninger i den virkelige verden mellem telefoner. Efter lidt offentlig skældsord (og nogle private samtaler) fra teknologipublikationer, industriledere og offentligheden fik de fleste producenter beskeden om, at benchmark-snyd simpelthen ikke var acceptabelt, og stoppede som en resultat. De fleste af de få, der ikke stoppede på det tidspunkt, stoppede kort efter, da der var foretaget væsentlige ændringer til, hvor mange benchmarks der kører, i et forsøg på at modvirke benchmark snyd (ved at reducere fordelen fra det). Mange benchmarks blev gjort længere, så den termiske drosling fra maksimering af clockhastigheder ville blive synlig med det samme.
Når vi interviewet John Poole, skaberen af Geekbench, emnet for benchmark-snyd, og hvad virksomheder som Primate Labs kan gøre for at forhindre, at det dukkede op. Primate Labs gjorde især Geekbench 4 en del længere end Geekbench 3, til dels for at reducere virkningerne af benchmark-snyd. Reduktion af fordelene for at sikre, at udviklingen omkostninger ved benchmark snyd er ikke det værd.
"Problemet er, at når vi først har disse store køretider, begynder du at spille ting ved at skrue op for dit ur hastigheder eller deaktivering af regulatorer eller noget i den stil, vil du begynde at udsætte reel reel fare i telefon... Hvis du vil spille det... du får ikke så meget ud af det. Du får måske stadig et par procent, men er det virkelig det værd?" - John Poole
Hvad skete der
Desværre må vi rapportere, at nogle OEM'er er begyndt at snyde igen, hvilket betyder, at vi skal være på udkig igen. Heldigvis er producenterne blevet mere og mere lydhøre over for problemer som dette, og med den rette opmærksomhed, kan dette løses hurtigt. Det er lidt chokerende at se producenter implementere benchmark snyd i lyset af hvor slemt tilbageslaget var sidste gang det blev forsøgt (med nogle benchmarks, der fuldstændig udelukker snydeenheder fra deres ydeevne lister). Med det modreaktion i kontrast til, hvor lille præstationsgevinsten fra benchmark-snyd typisk er (hos de fleste af forsøgene, der resulterede i en stigning på mindre end 5 % sidste gang), havde vi virkelig håbet, at det hele ville være bagud os.
Timingen af dette forsøg er især uhensigtsmæssig, da benchmark-snyd for et par måneder siden efterlod verden af at være et rent entusiast bekymring, og trådte ind i den offentlige sfære, da Volkswagen og Fiat Chrysler begge blev taget i at snyde med deres emissioner benchmarks. Begge virksomheder implementerede software til at registrere, hvornår deres dieselbiler blev underkastet emissionstest, og fik dem til at skifte til en lavemissionstilstand der så deres brændstoføkonomi falde i et forsøg på at konkurrere med benzinbiler i brændstofeffektivitet, mens de stadig holdt sig inden for de lovmæssige grænser for emissioner tests. Indtil videre har skandalen resulteret i milliarder i bøder, titusindvis af milliarder af tilbagekaldelsesomkostninger og anklager – bestemt ikke den slags gengældelse OEM'er ville nogensinde se for at oppuste deres benchmarkscore, som udelukkende er til brugersammenligninger og ikke bruges til at måle nogen regulering krav.
Mens undersøge, hvordan Qualcomm opnår hurtigere appåbningshastigheder på den dengang nye Qualcomm Snapdragon 821 bemærkede vi noget mærkeligt på OnePlus 3T at vi ikke kunne gengive på Xiaomi Mi Note 2 eller den Google Pixel XL, blandt andre Snapdragon 821-enheder. Vores chefredaktør, Mario Serrafero, brugte Qualcomm Trepn og Snapdragon Performance Visualizer til at overvåge, hvordan Qualcomm "booster" CPU'en urhastighed ved åbning af apps, og bemærkede, at visse apps på OnePlus 3T ikke faldt tilbage til deres normale tomgangshastigheder efter åbning. Som en generel tommelfingerregel undgår vi at teste benchmarks med præstationsovervågningsværktøjer åbne, når det er muligt på grund af de ekstra præstationsomkostninger, de medfører (især i ikke-Snapdragon-enheder, hvor de ikke er officielle skrivebordsværktøjer), men i denne hændelse hjalp de os med at bemærke en mærkelig adfærd, som vi sandsynligvis ville have savnet Ellers.
Når du går ind i visse benchmarking-apps, ville OnePlus 3Ts kerner forblive over 0,98 GHz for de små kerner og 1,29 GHz for de store kerner, selv når CPU-belastningen faldt til 0%. Dette er ret mærkeligt, da begge sæt kerner normalt falder til 0,31 GHz på OnePlus 3T, når der ikke er nogen belastning. Da vi først så dette, var vi bekymrede for, at OnePlus' CPU-skalering simpelthen var sat lidt mærkeligt, Men ved yderligere test kom vi til den konklusion, at OnePlus skal være målrettet specifikt applikationer. Vores hypotese var, at OnePlus målrettede disse benchmarks ved navn og gik ind i en alternativ CPU-skaleringstilstand for at pumpe deres benchmarkscore op. En af vores største bekymringer var, at OnePlus muligvis satte løsere termiske begrænsninger i denne tilstand for at undgå de problemer, de havde med OnePlus One, OnePlus X og OnePlus 2, hvor telefonerne håndterede de ekstra kerner, der kom online til multi-core sektionen af Geekbench dårligt, og af og til drosler betydeligt ned som et resultat (til det punkt, hvor OnePlus X nogle gange scorede lavere i multikernesektionen end i singlen kerneafsnit). Du kan finde kraftig drosling i vores OnePlus 2 anmeldelse, hvor vi fandt ud af, at enheden kunne slippe op til 50% af sin Geekbench 3 multi-core score. Senere, da vi begyndte at sammenligne drosling og termik på tværs af enheder, OnePlus 2 blev et lærebogseksempel på, hvad OEM'er bør undgå.
Vi nåede ud til holdet kl Primate Labs (skaberne af Geekbench), som var medvirkende til at afsløre den første bølge af benchmark-snyd, og samarbejdede med dem for yderligere test. Vi bragte en OnePlus 3T til Primate Labs' kontor i Toronto for en indledende analyse. Den indledende test inkluderede et ROM-dump, som fandt ud af, at OnePlus 3T direkte ledte efter en hel del apps ved navn. Mest bemærkelsesværdigt var OnePlus 3T på udkig efter Geekbench, AnTuTu, Androbench, Quadrant, Vellamo og GFXBench. Da vi på dette tidspunkt havde ret klare beviser på, at OnePlus var involveret i benchmark-snyd, byggede Primate Labs en "Bobs minigolfputt" version af Geekbench 4 til os. Takket være væsentlige ændringer mellem Geekbench 3 og 4, den “Minigolf” version skulle genopbygges fra bunden, specielt til denne test. Denne version af Geekbench 4 er designet til at undgå enhver benchmark-detektion, for at tillade Geekbench at køre som normalt applikation på telefoner, der snyder (går ud over pakkens omdøbning, der narre de fleste forsøg på benchmark at snyde).
Et overraskende eksempel
Umiddelbart efter åbning af appen var forskellen tydelig. OnePlus 3T var i tomgang ved 0,31 GHz, som den gør i de fleste apps, snarere end ved 1,29 GHz for de store kerner og 0,98 GHz for de små kerner, som den gør i den almindelige Geekbench-app. OnePlus gjorde den CPU-guvernør mere aggressiv, hvilket resulterede i et praktisk kunstigt urhastighedsgulv i Geekbench, som ikke var der i den skjulte Geekbench-bygning. Det var ikke baseret på CPU-arbejdsbelastningen, men snarere på appens pakkenavn, som den skjulte build kunne narre. Mens forskellen i individuelle kørsler var minimal, skinner de termiske droslingsafspændinger i vores vedvarende præstationstest, vist nedenfor.
Fra vores test ser det ud til, at dette har været en "funktion" i Hydrogen OS i et stykke tid nu og ikke blev tilføjet til Oxygen OS, før fællesskabet er opbygget før Nougat-udgivelsen (efter to ROM'er blev slået sammen). Det er lidt skuffende at se, især i lyset af de softwareproblemer, som OnePlus har haft i denne måned efter sammenlægningen af ROM'erne, fra bootloaders sårbarheder til GPL-overholdelsesproblemer. Vi håber, at når støvet lægger sig efter sammenlægningen af de to hold, vil OnePlus vende tilbage til formen og fortsætte med at positionere sig selv som en udviklervenlig mulighed.
Med “Minigolf” version af Geekbench i hånden, gik vi ud og begyndte også at teste andre telefoner for benchmark snyd. Heldigvis viser vores test ingen snyd fra de virksomheder, der var involveret i skandalen for et halvt årti siden. HTC, Xiaomi, Huawei, Honor, Google, Sony og andre ser ud til at have ensartede resultater mellem den almindelige Geekbench-bygning og “Minigolf” bygge videre på vores testenheder.
Desværre fandt vi mulige beviser for benchmark-snyd, som vi endnu ikke har kunnet bekræfte fra et par andre virksomheder, som vi vil undersøge nærmere. Det allerværste eksempel på dette var i den Exynos 8890-drevne Meizu Pro 6 Plus, som tog benchmark-snyd til en anden yderlighed.
Et frygteligt eksempel
Meizu har historisk set deres CPU-skalering ekstremt konservativt. Især sætter de ofte deres telefoner op, så de store kerner sjældent kommer online, selv når de er i deres "performance mode", hvilket gør flagskibsprocessorerne (som de fremragende Exynos 8890), som de sætter i deres flagskibstelefoner, fungerer som mellemtoneprocessorer. Dette kom til hovedet sidste år, da Anandtech kaldte Meizu ud for deres dårlige ydeevne på Anandtechs JavaScript-benchmarks på den Mediatek Helio X25-baserede Meizu Pro 6, og bemærkede, at de store kerner forblev offline i det meste af testen (når testen skulle have kørt næsten udelukkende på den store kerner). Anandtech bemærkede i sidste uge, at en softwareopdatering var blevet skubbet til Meizu Pro 6, som endelig tillod Meizu at bruge disse kerner fuldt ud. Anandtechs smartphone seniorredaktør, Matt Humrick, bemærkede at "Efter opdatering til Flyme OS 5.2.5.0G yder PRO 6 væsentligt bedre. Kraken, WebXPRT 2015 og JetStream-resultaterne forbedres med omkring 2x-2,5x. Meizu justerede tilsyneladende belastningstærskelværdien, hvilket tillod tråde at migrere til A72-kernerne hyppigere for bedre ydeevne."
Desværre ser det ud til, at snarere end at forbedre CPU-skaleringen for deres nye enheder for at opnå bedre benchmarkscore, ser de ud til at have sat telefonen til at skifte til at bruge de store kerner, når visse apps er løb.
Når du åbner en benchmarking-app, anbefaler vores Meizu Pro 6 Plus, at du skifter til "Performance Mode" (som alene er nok til at bekræfte, at de leder efter specifikke pakkenavne), og det ser ud til at gøre en væsentlig forskel. Når telefonen er i standard "Balance Mode", scorer telefonen konsekvent omkring 604 og 2220 på Geekbenchs single-core og multi-core sektioner, men i "Performance Mode" scorer 1473 og 3906, hovedsagelig takket være de store kerner, der forbliver slukket i det meste af testen i "Balance Mode", og tænder i "Performance Mode". Meizu ser ud til at låse de små kerner til deres maksimale hastighed på 1,48 GHz og sætter et hårdt gulv for to af deres store kerner på 1,46 GHz, når de kører Geekbench mens du er i "Performance Mode" (hvor de to andre store kerner får lov til at skalere frit og ret aggressivt), hvilket vi ikke kan se, når kører “Minigolf” bygge.
Selvom det kan være en fin funktion at kunne vælge mellem en højeffekttilstand og en laveffekttilstand, ser det i dette tilfælde ud til at være intet andet end et salontrick. Meizu Pro 6 Plus ser anstændige resultater i "Performance Mode" for den almindelige Geekbench-app, men når du bruger “Minigolf” bygget af Geekbench, falder den lige tilbage på samme niveau af ydeevne, som den har, når den er indstillet til "Balance Mode". Den højere ydeevnetilstand på Meizu Pro 6 Plus er kun til benchmarking, ikke til faktisk daglig brug.
En ting at bemærke er, at da vi testede Meizu Pro 6 Plus i "Performance Mode" med hemmeligheden bygget af Geekbench, kom de store kerner online, hvis vi optog urhastighederne med Qualcomm Trepn. Vi har endnu ikke fastslået, om Meizu genkender, at Trepn kører og tænder for de store kerner i del på grund af det, eller hvis det simpelthen tænder for de store kerner på grund af den ekstra CPU-belastning, som det skaber. Selvom det kan lyde kontraintuitivt, at en ekstra belastning i baggrunden (såsom når vi holdt præstationsgrafer på under testen) ville øge resultaterne af et benchmark, kunne Meizus konservative skalering betyde, at den ekstra overhead var nok til at skubbe det ud over kanten og kalde de store kerner i gang og dermed forbedre ydeevnen for alle opgaver.
Når modtagelige OEM'er adresserer feedback...
Efter vores test kontaktede vi OnePlus om de problemer, vi fandt. Som svar, OnePlus lovede hurtigt at stoppe med at målrette benchmarking-apps med deres benchmark-snyd, men har stadig til hensigt at beholde det til spil (som også bliver benchmarked). I en fremtidig build af OxygenOS vil denne mekanisme ikke blive udløst af benchmarks. OnePlus har taget imod vores forslag om også at tilføje en skifte, så brugerne ved, hvad der foregår under motorhjelmen, og i det mindste burde den uretfærdige og vildledende fordel i benchmarks være rettet. På grund af den kinesiske nytårsferie og deres funktionsefterslæb kan det dog tage et stykke tid, før vi ser brugervendte tilpasningsmuligheder for denne ydeevnefunktion. Selvom det alene er en forbedring at korrigere adfærden, er det stadig en smule skuffende at se regelmæssigt applikationer (som spil), da det er en krykke at målrette mod specifikke apps, i stedet for at forbedre den faktiske ydeevne skalering. Ved kunstigt at booste processorens aggressivitet og dermed clockhastighederne for specifikke apps i stedet for at forbedre deres telefoners evne til at identificere, hvornår den faktisk har brug for højere urhastigheder skaber OnePlus inkonsekvent ydeevne for deres telefoner, hvilket kun bliver mere tydeligt, efterhånden som telefonen bliver ældre, og flere spil, som OnePlus ikke har målrettet mod, er frigivet. Implementeringen tillader dog i øjeblikket spil at yde bedre. OnePlus leverede også en erklæring til denne artikel, som du kan læse nedenfor:
'For at give brugerne en bedre brugeroplevelse i ressourcekrævende apps og spil, især grafisk intensive de, implementerede vi visse mekanismer i fællesskabet og Nougat builds for at få processoren til at køre mere aggressivt. Udløserprocessen for benchmarking af apps vil ikke være til stede i kommende OxygenOS builds på OnePlus 3 og OnePlus 3T.'
Vi er glade for at høre, at OnePlus vil fjerne benchmark-snyden fra deres telefoner. Fremadrettet vil vi fortsætte med at forsøge at presse OEM'er til at være mere forbrugervenlige, når det er muligt, og vi vil holde øje med fremtidig benchmark-snyd.
Desværre er det eneste rigtige svar på denne form for bedrag konstant årvågenhed. Som smartphone-entusiastfællesskabet skal vi holde øjnene ude for forsøg på at bedrage brugere som dette. Det er ikke selve benchmarkscorerne, vi er interesserede i, men derimod hvad benchmarks siger om telefonens ydeevne. Mens benchmark snyd endnu ikke var aktiv på OnePlus 3 da vi gennemgik det, var en simpel softwareopdatering nok til at tilføje denne vildledende "funktion", og illustrerer tydeligt, at det ikke er tilfældet at kontrollere enhederne for benchmark-snyd, når de lanceres første gang nok. Problemer som denne kan tilføjes dage, uger, måneder eller endda år efter enhedens lancering, kunstigt oppumpning af de globale gennemsnit indsamlet af benchmarks måneder frem, hvilket påvirker den endelige database resultat. Det skal bemærkes, at selv med disse tweaks, som producenterne var nødt til at investere tid og penge for at udvikle, vi ser typisk kun et par procentpoints stigning i benchmarkscore (undtagen et par udkantssager som Meizu, hvor snyderiet dækker over meget større problemer). Et par procentpoint, hvilket er meget mindre end forskellen mellem de bedst ydende og dårligst ydende enheder. Vi vil dog hævde, at med enheder, der kører mere og mere ens hardware, kan disse ekstra procentpoint være den afgørende faktor i de rangordningsdiagrammer, som brugerne i sidste ende slår op. Bedre driveroptimering og smartere CPU-skalering kan have en absolut massiv effekt på enhedens ydeevne, med forskellen mellem scoren for den bedst ydende Qualcomm Snapdragon 820-baserede enhed og den dårligst ydende (fra en større OEM) over 20 % på Geekbench. Tyve procent fra driveroptimering i stedet for et par procentpoint fra at bruge tid og penge på at bedrage dine brugere. Og det taler kun om udviklingsindsatsen, der kan påvirke benchmarkscore. Mange af de største fordele ved at investere i at forbedre en enheds software dukker ikke altid op på benchmarks, hvor OnePlus tilbyder fremragende ydelse i den virkelige verden i deres enheder. Det burde virkelig være klart, hvor en virksomheds udviklingsindsats skal fokuseres i dette tilfælde. Vi når ud til flere virksomheder, der snyder med benchmarks, efterhånden som vi finder dem, og vi håber, at de er lige så modtagelige som OnePlus.
Vi vil gerne endnu en gang takke teamet hos Primate Labs for at arbejde sammen med os for at afdække dette problem. Det ville have været væsentligt sværere at teste korrekt for Benchmark-snyd uden "Mini Golf"-udgaven af Geekbench.