Slik tester vi, fullt ut

Riggen

Samme maskin, samme linje, samme innhold

Hver klient i en sammenligning kjører på én maskin, mot de samme leverandørene, på det samme innholdet, innenfor den samme omgangen. Ingenting føres videre fra en tidligere dag.

Maskinene. En Apple M1 Ultra på en 10 GbE-linje i Europa, og en M3 Ultra på en tregere linje i USA. Sammenligninger blander aldri de to: en tabell er én maskin.
Linjen betyr mer enn prosessoren. På en 10 GbE-linje klarer de fleste klienter å mette forbindelsen på en lett jobb, og derfor er de interessante scenarioene de der noe annet enn ren båndbredde avgjør utfallet.
Leverandører. Fem kommersielle leverandører, det samme settet for hver klient, over TLS. Vi holder én leverandør utenfor disse omgangene fordi den begrenser hvor mange steder som kan koble til samtidig, noe som ville gjøre en delt testmaskin urimelig mot den som kjørte som nummer to.
Tilkoblinger. Hver klient får det samme antallet per leverandør i en gitt omgang, og omgangen sier hvilket. Flere er ikke automatisk bedre; vi har målt vår egen klient holde den samme sluttiden gjennom en nidobbel endring i antallet tilkoblinger.

Regelen som avgjør alt

En klient bedømmes på fila, ikke på sin egen statusmelding

Dette er det aller viktigste på denne siden. Hver omgang avsluttes med å finne den største fila klienten produserte, hvor som helst i utdataene, og hashe den mot en kjent korrekt kopi. Størrelse og MD5, i hver eneste omgang, ikke på en stikkprøve.

Vi gjør det fordi en klients egen melding om suksess ikke er pålitelig bevis. Vi har målt en klient som meldte done på en jobb der utdatamappen var tom. Vi har målt en annen som meldte Completed etter å ha levert rå arkivbind den aldri pakket ut. Et mye brukt reparasjonsverktøy avslutter med feilkode etter en vellykket reparasjon. Ingen av de klientene løy; statustekster betyr ganske enkelt ulike ting for ulike forfattere, og en måling som stoler på dem, måler ordvalg framfor atferd.

Målstreken er derfor den samme for alle: innholdet finnes, i riktig størrelse, med riktig hash. Stopper en klient før det, får den ingen tid, og hele kolonnen blir merket framfor stilltiende utelatt. En treg klient som blir ferdig, gjør det bedre enn en rask som ikke gjør det, og tabellen skal si det.

Følgen er at en manglende fullføring er et resultat, ikke en feil fra vår side. Når vi publiserer en, beskriver vi sluttilstanden i vanlige ord, inkludert alt som tyder på at den er særegen for akkurat den jobben framfor generell, og vi sier hva klienten gjorde i stedet for å bli ferdig.

Rekkefølge og gjentakelse

Hvorfor omganger veksler, og hvorfor enkeltkjøringer ikke publiseres

Leverandørenes gjennomstrømning varierer fra minutt til minutt, iblant med en faktor to eller tre. To målinger tatt på ulike tidspunkt måler delvis været.

Klientene kjører derfor rett etter hverandre og om hverandre, og rekkefølgen snus mellom gjentakelsene, slik at ingen klient alltid er den som går først ut på en varm eller kald linje. Et resultat er mønsteret over gjentakelsene, ikke den beste kjøringen. Når spredningen er stor, publiserer vi intervallet framfor et gjennomsnitt som ville skjult den, og hvis vi ikke vet hvorfor tallene til en klient spriker, sier vi det i stedet for å finne på en årsak.

Sammenligninger på tvers av ulike omganger unngås der det går an. Krever en påstand to tall, kjører vi heller begge om igjen i én omgang enn å trekke den ene dagens tall fra den andres, fordi riggens tilstand, leverandørforholdene og klientversjonene alle driver. Når vi sammenligner to av våre egne bygg, kjører begge i samme omgang, vekselvis, på det samme innholdet.

De uglamorøse kontrollene

Hva som kjører før og under hver omgang

De fleste finnes fordi en taus feil en gang ga et friskt utseende, publiserbart og galt tall. Hver av dem kjører nå automatisk og stanser omgangen framfor å advare.

Hver leverandør svarer før omgangen starter. En omgang kjørt mens to leverandører er nede, måler et avbrudd, og det ser nøyaktig ut som en treg klient.
Programfila identifiseres med hash før hver omgang, ikke med filnavn eller versjonstekst. To av byggene våre oppga samme versjonsnummer selv om de skilte seg med 88 innsjekkinger; bare hashen skiller dem, og tabellene oppgir den.
Hver klient kjører som maskinnær kode. På Apple-maskiner kan et feilbygd hjelpeprogram kjøre stille under oversettelse, noe som koster prosessortid som hører til vårt pakkevalg og ikke til klientens kode. Vi sjekker prosessen som kjører, ikke bare fila.
Grensene for åpne filer heves for alle, likt. macOS starter programmer med en grense på 256 åpne filer, som et fullt sett tilkoblinger kan overskride. En klient som treffer den, pleier å forsvinne uten krasjrapport, noe som leses nøyaktig som en svikt i programvaren. En konkurrents tilsynelatende manglende fullføring viste seg å være dette; med hevet grense ble den identiske jobben ferdig på 44 sekunder.
Disktrafikk registreres per omgang, noe som samtidig kontrollerer at ingenting annet brukte maskinen. Disse tellerne dekker hele disken framfor ett program, så hvis en annen jobb kjørte, ville arbeidet dens dukke opp inne i målingene våre. Flate avlesninger gjennom en omgang er hvordan vi vet at et resultat tilhører den klienten det nevner.
Hver klient skriver til sitt eget utdatatre, og treet tømmes før hver omgang, slik at ingen kjøring kan bli tilfredsstilt av fila fra en tidligere kjøring.

Der en klient trenger bestemte innstillinger for å yte godt, får den dem, og omgangen sier hvilke. Eksempler: forespørselskø slått på der en klient leveres med den av, duplikatsjekk slått av når den samme jobben lastes ned gjentatte ganger, og utpakkingshjelpere hentet fra klientens egen pakke framfor en systemkopi. Målet er at hver klient måles på sitt beste framfor på standardverdiene sine, siden standardverdier er en annen diskusjon enn evne.

Hva vi ikke vil gjøre

Grensene for disse tallene

Vi publiserer ikke et tall vi ikke har målt. Er et tall utledet framfor observert, merkes det som utledet, og vi lar heller et hull stå enn å fylle det med regnestykker som leses som en måling.
Vi retter ikke stille opp et tapende resultat. En omgang vi taper, blir stående publisert til en ny kjøring erstatter den, og når et tap blir til en seier, får endringen en forklaring ved siden av tabellen framfor en taus retting.
Leverandøromgangene er ennå ikke uavhengig reproduserbare, fordi innholdet ikke er vårt å dele ut. Komponenttestene, som bruker generert innhold, er det. Vi forbereder testfiler vi kan publisere, slik at også leverandøromgangene blir mulige å etterprøve.
Dette er våre målinger av andres programvare. Hver versjon navngis og dateres, og når en klient slipper en ny utgave, kjører vi om de omgangene den påvirker framfor å la en utdatert sammenligning bli stående. Mener du at et resultat er galt, er innstillinger og versjoner publisert slik at det går an å innvende konkret.