Come collaudiamo, per esteso

Il banco di prova

Stessa macchina, stessa linea, stesso contenuto

Ogni client di un confronto gira su una sola macchina, verso gli stessi provider, sullo stesso contenuto, nella stessa tornata. Nulla viene riportato da un giorno precedente.

Le macchine. Un Apple M1 Ultra su una linea 10 GbE in Europa, e un M3 Ultra su una linea più lenta negli Stati Uniti. I confronti non mescolano mai le due: una tabella è una macchina.
La linea conta più del processore. Su una linea 10 GbE la maggior parte dei client riesce a saturare la connessione su un lavoro facile, ed è per questo che gli scenari interessanti sono quelli in cui a decidere l'esito è qualcosa di diverso dalla banda grezza.
Provider. Cinque provider commerciali, lo stesso insieme per ogni client, su TLS. Escludiamo un provider da queste tornate perché limita quante postazioni possono collegarsi insieme, il che renderebbe una macchina di prova condivisa ingiusta verso chi gira per secondo.
Connessioni. Ogni client riceve lo stesso numero per provider in una data tornata, e la tornata dice quale. Di più non è automaticamente meglio; abbiamo misurato il nostro stesso client mantenere lo stesso tempo di arrivo su una variazione di nove volte nel numero di connessioni.

La regola che decide tutto

Un client si giudica sul file, non sul suo messaggio di stato

È la cosa più importante di questa pagina. Ogni prova finisce cercando il file più grande prodotto dal client, ovunque si trovi nel suo output, e calcolandone l'hash contro una copia di riferimento. Dimensione e MD5, a ogni prova, non su un campione.

Lo facciamo perché il rapporto di successo di un client non è una prova affidabile. Abbiamo misurato un client che segnalava done su un lavoro la cui cartella di uscita era vuota. Ne abbiamo misurato un altro che segnalava Completed avendo consegnato volumi d'archivio grezzi che non aveva mai scompattato. Uno strumento di riparazione molto diffuso esce con un codice di errore dopo una riparazione riuscita. Nessuno di quei client mentiva; le stringhe di stato semplicemente significano cose diverse per autori diversi, e un benchmark che si fida di loro misura lessico anziché comportamento.

Il traguardo è quindi lo stesso per tutti: il contenuto esiste, della dimensione giusta, con l'hash giusto. Se un client si ferma prima, non ottiene un tempo, e l'intera colonna viene segnalata anziché omessa in silenzio. Un client lento che finisce sta facendo meglio di uno veloce che non finisce, e la tabella deve dirlo.

Il corollario è che un mancato arrivo è un risultato, non un nostro errore. Quando ne pubblichiamo uno descriviamo lo stato finale in termini semplici, compreso tutto ciò che suggerisce che sia specifico di quel lavoro anziché generale, e diciamo cosa ha fatto il client invece di finire.

Ordine e ripetizione

Perché le prove si alternano, e perché le esecuzioni singole non si pubblicano

La velocità dei provider varia di minuto in minuto, a volte di un fattore due o tre. Due misure prese in momenti diversi misurano in parte il meteo.

I client girano quindi uno dopo l'altro e alternati, e l'ordine si inverte tra le ripetizioni, così nessun client è sempre quello che entra per primo su una linea calda o fredda. Un risultato è l'andamento su tutte le ripetizioni, non la corsa migliore. Quando la dispersione è ampia, pubblichiamo l'intervallo invece di una media che lo nasconderebbe, e se non sappiamo perché i numeri di un client sono dispersi, lo diciamo invece di inventare una causa.

I confronti tra tornate diverse si evitano ovunque possibile. Se un'affermazione richiede due numeri, preferiamo rifar correre entrambi in un'unica tornata piuttosto che sottrarre la cifra di un giorno a quella di un altro, perché lo stato del banco, le condizioni dei provider e le versioni dei client vanno tutti alla deriva. Quando confrontiamo due nostre build, entrambe girano nella stessa tornata, alternandosi, sullo stesso contenuto.

I controlli poco appariscenti

Cosa gira prima e durante ogni prova

La maggior parte esiste perché un guasto silenzioso una volta ha prodotto un numero dall'aria sana, pubblicabile e sbagliato. Ognuno ora gira in automatico e ferma la tornata invece di avvisare.

Ogni provider risponde prima che la prova inizi. Una prova eseguita mentre due provider sono giù misura un disservizio, e sembra esattamente un client lento.
Il binario viene identificato per hash prima di ogni prova, non per nome di file o stringa di versione. Due nostre build riportavano lo stesso numero di versione pur differendo di 88 commit; solo l'hash le distingue, e le tabelle lo citano.
Ogni client gira come codice nativo. Sulle macchine Apple un ausiliario costruito male può girare in silenzio sotto traduzione, il che costa tempo di processore che appartiene alla nostra scelta di impacchettamento e non al codice del client. Controlliamo il processo in esecuzione, non solo il file.
I limiti di file aperti vengono alzati per tutti, in modo identico. macOS avvia i programmi con un limite di 256 file aperti, che un insieme completo di connessioni può superare. Un client che ci arriva tende a sparire senza rapporto di crash, il che si legge esattamente come un difetto del software. L'apparente mancato arrivo di un concorrente si è rivelato essere questo; alzato il limite, lo stesso identico lavoro è finito in 44 secondi.
Il traffico su disco viene registrato per ogni prova, il che serve anche a verificare che nient'altro stesse usando la macchina. Quei contatori coprono l'intero disco anziché un singolo programma, quindi se girasse un secondo lavoro, il suo operato comparirebbe dentro le nostre misure. Letture piatte lungo tutta una tornata sono il modo in cui sappiamo che un risultato appartiene al client che nomina.
Ogni client scrive nel proprio albero di uscita, e l'albero viene cancellato prima di ogni prova, così nessuna esecuzione può essere soddisfatta dal file di un'esecuzione precedente.

Dove un client ha bisogno di impostazioni particolari per rendere bene, le riceve, e la tornata dice quali. Esempi: pipelining delle richieste attivato dove un client lo consegna spento, controllo dei duplicati disattivato quando lo stesso lavoro viene scaricato ripetutamente, e ausiliari di scompattamento presi dal pacchetto del client anziché da una copia di sistema. Lo scopo è che ogni client sia misurato al suo meglio anziché ai suoi valori predefiniti, dato che i predefiniti sono una discussione separata dalla capacità.

Cosa non faremo

I limiti di questi numeri

Non pubblichiamo una cifra che non abbiamo misurato. Se un numero è ricavato anziché osservato, viene etichettato come ricavato, e preferiamo lasciare un vuoto piuttosto che riempirlo con un calcolo che si legge come una misura.
Non aggiorniamo in sordina un risultato perdente. Una prova che perdiamo resta pubblicata finché una nuova esecuzione non la sostituisce, e quando una sconfitta diventa una vittoria il cambiamento riceve una spiegazione accanto alla tabella anziché una modifica silenziosa.
Le prove con i provider non sono ancora riproducibili in modo indipendente, perché il contenuto non è nostro da distribuire. I test sui componenti, che usano contenuto generato, lo sono. Stiamo preparando file di prova pubblicabili perché anche le prove con i provider diventino verificabili.
Questi sono i nostri benchmark del software di altre persone. Ogni versione è nominata e datata, e quando un client pubblica una nuova release rifacciamo correre le prove che tocca anziché lasciare in piedi un confronto scaduto. Se pensi che un risultato sia sbagliato, impostazioni e versioni sono pubblicate perché lo si possa contestare in modo specifico.