Sådan tester vi, det hele

Riggen

Samme maskine, samme linje, samme indhold

Hver klient i en sammenligning kører på én maskine, mod de samme udbydere, på det samme indhold, inden for den samme omgang. Intet bliver ført videre fra en tidligere dag.

Maskinerne. En Apple M1 Ultra på en 10 GbE-linje i Europa, og en M3 Ultra på en langsommere linje i USA. Sammenligninger blander aldrig de to: en tabel er én maskine.
Linjen betyder mere end processoren. På en 10 GbE-linje kan de fleste klienter mætte forbindelsen på en let opgave, og derfor er de interessante scenarier dem, hvor noget andet end ren båndbredde afgør udfaldet.
Udbydere. Fem kommercielle udbydere, det samme sæt for hver klient, over TLS. Vi udelader én udbyder fra disse omgange, fordi den begrænser, hvor mange steder der må forbinde samtidig, hvilket ville gøre en delt testmaskine urimelig over for den, der kørte som nummer to.
Forbindelser. Hver klient får det samme antal pr. udbyder i en given omgang, og omgangen angiver hvilket. Flere er ikke automatisk bedre; vi har målt vores egen klient holde den samme sluttid hen over en nidobbelt ændring i antallet af forbindelser.

Reglen der afgør alt

En klient bedømmes på filen, ikke på sin egen statusbesked

Dette er det allervigtigste på denne side. Hver omgang slutter med at finde den største fil, klienten har frembragt, hvor som helst i dens output, og hashe den mod en kendt korrekt kopi. Størrelse og MD5, i hver eneste omgang, ikke på en stikprøve.

Vi gør det, fordi en klients egen melding om succes ikke er pålideligt bevis. Vi har målt en klient melde done på en opgave, hvis outputmappe var tom. Vi har målt en anden melde Completed efter at have leveret rå arkivbind, den aldrig pakkede ud. Et udbredt reparationsværktøj afslutter med en fejlkode efter en vellykket reparation. Ingen af de klienter løj; statustekster betyder ganske enkelt forskellige ting for forskellige forfattere, og en måling, der stoler på dem, måler ordvalg frem for adfærd.

Målstregen er derfor den samme for alle: indholdet findes, i den rigtige størrelse, med den rigtige hash. Standser en klient inden da, får den ingen tid, og hele kolonnen bliver markeret frem for stiltiende udeladt. En langsom klient, der bliver færdig, klarer sig bedre end en hurtig, der ikke gør, og tabellen skal sige det.

Følgeslutningen er, at en manglende gennemførelse er et resultat, ikke en fejl fra vores side. Når vi offentliggør en, beskriver vi sluttilstanden i almindelige vendinger, herunder alt der tyder på, at den er særegen for netop den opgave frem for generel, og vi siger, hvad klienten gjorde i stedet for at blive færdig.

Rækkefølge og gentagelse

Hvorfor omgange skiftes, og hvorfor enkeltkørsler ikke offentliggøres

Udbydernes gennemløb svinger fra minut til minut, undertiden med en faktor to eller tre. To målinger taget på forskellige tidspunkter måler til dels vejret.

Klienter kører derfor lige efter hinanden og på skift, og rækkefølgen vendes mellem gentagelserne, så ingen klient altid er den, der går først ud på en varm eller kold linje. Et resultat er mønsteret på tværs af gentagelserne, ikke den bedste kørsel. Når spredningen er stor, offentliggør vi intervallet frem for et gennemsnit, der ville skjule den, og hvis vi ikke ved, hvorfor en klients tal spreder sig, siger vi det i stedet for at opfinde en årsag.

Sammenligninger på tværs af forskellige omgange undgås, hvor det kan lade sig gøre. Kræver en påstand to tal, kører vi hellere begge om i én omgang end at trække den ene dags tal fra den andens, fordi riggens tilstand, udbyderforholdene og klientversionerne alle skrider. Når vi sammenligner to af vores egne builds, kører begge i samme omgang, skiftevis, på det samme indhold.

De uglamourøse kontroller

Hvad der kører før og under hver omgang

De fleste findes, fordi en tavs fejl engang frembragte et sundt udseende, offentliggørelsesegnet og forkert tal. Hver enkelt kører nu automatisk og standser omgangen frem for at advare.

Alle udbydere svarer, før omgangen begynder. En omgang kørt, mens to udbydere er nede, måler et nedbrud, og det ser nøjagtigt ud som en langsom klient.
Programfilen identificeres ved hash før hver omgang, ikke ved filnavn eller versionstekst. To af vores builds oplyste det samme versionsnummer, selv om de adskilte sig med 88 commits; kun hashen skiller dem ad, og tabellerne angiver den.
Alle klienter kører som hjemmehørende kode. På Apple-maskiner kan et forkert bygget hjælpeprogram tavst køre under oversættelse, hvilket koster processortid, der hører til vores pakningsvalg og ikke til klientens kode. Vi kontrollerer den kørende proces, ikke bare filen.
Grænserne for åbne filer hæves for alle, ens. macOS starter programmer med en grænse på 256 åbne filer, som et fuldt sæt forbindelser kan overskride. En klient, der rammer den, plejer at forsvinde uden nedbrudsrapport, hvilket læses nøjagtigt som en fejl i softwaren. En konkurrents tilsyneladende manglende gennemførelse viste sig at være dette; med hævet grænse blev den identiske opgave færdig på 44 sekunder.
Disktrafik registreres pr. omgang, hvilket samtidig kontrollerer, at intet andet brugte maskinen. De tællere dækker hele disken frem for ét program, så hvis en anden opgave kørte, ville dens arbejde dukke op inde i vores målinger. Flade aflæsninger gennem en omgang er, hvordan vi ved, at et resultat tilhører den klient, det nævner.
Hver klient skriver til sit eget outputtræ, og træet ryddes før hver omgang, så ingen kørsel kan blive tilfredsstillet af en tidligere kørsels fil.

Hvor en klient har brug for bestemte indstillinger for at yde godt, får den dem, og omgangen angiver hvilke. Eksempler: forespørgselskø slået til, hvor en klient leveres med den slået fra, dublettjek slået fra, når den samme opgave hentes gentagne gange, og udpakningshjælpere taget fra klientens egen pakke frem for en systemkopi. Formålet er, at hver klient måles, når den er bedst, frem for ved sine standardværdier, eftersom standardværdier er en anden diskussion end formåen.

Hvad vi ikke vil gøre

Grænserne for disse tal

Vi offentliggør ikke et tal, vi ikke har målt. Er et tal udledt frem for observeret, mærkes det som udledt, og vi lader hellere et hul stå end fylder det med regnestykker, der læses som en måling.
Vi retter ikke stiltiende et tabende resultat. En omgang, vi taber, bliver stående offentliggjort, indtil en ny kørsel afløser den, og når et tab bliver til en sejr, får ændringen en forklaring ved siden af tabellen frem for en tavs rettelse.
Udbyderomgangene er endnu ikke uafhængigt reproducerbare, fordi indholdet ikke er vores at videregive. Komponenttestene, der bruger genereret indhold, er det. Vi forbereder testfiler, vi kan offentliggøre, så også udbyderomgangene bliver til at efterprøve.
Dette er vores målinger af andres software. Hver version bliver navngivet og dateret, og når en klient udsender en ny udgave, kører vi de omgange om, den påvirker, frem for at lade en forældet sammenligning blive stående. Mener du, at et resultat er forkert, er indstillinger og versioner offentliggjort, så der kan argumenteres konkret imod.