3. The Linux Benchmarking Toolkit (LBT)

Proporrò uno strumento base per testare sistemi Linux. Questa è una versione preliminare di un Linux Benchmarking Toolkit, da essere espansa e migliorata. Prendetela per come è, cioè una proposta. Se si pensa che questa non sia una valida suite di test, si è invitati a mandare una e-mail con le proprie critiche e saranno apportati i cambiamenti e migliorie se possibile. Prima di entrare nell'argomento, comunque, è consigliabile leggere questo HOWTO e i punti di riferimento menzionati: critiche informate sono le benvenute, vuoto criticismo no.

3.1 Razionale

Questo è solo il buonsenso:

1. Non dovrebbe prendere un giorno intero per andare. Quando si va al benchmarking comparativo, nessuno vuole spendere giorni tentando di immaginare il più veloce setup per un dato sistema. Idealmente l'intero set di benchmark dovrebbe prendere circa 15 minuti per completarsi su una macchina media.
2. Tutto il codice sorgente utilizzato per il programma deve essere liberamente disponibile su internet per ovvie ragioni.
3. I benchmark dovrebbero provvedere semplici indici che rispecchino le performance misurate.
4. Ci dovrebbe essere un misto di benchmark sintetici e applicativi
5. Ogni benchmark sintetico dovrebbe impiegare il relativo sottosistema alla sua massima capacità.
6. I risultati dei benchmark sintetici non dovrebbero essere unificati in un unico indice (che non rispetta l'intera idea che c'è dietro i benchmark sintetici, con considerevole perdita di informazioni).
7. I benchmark applicativi dovrebbero consistere in processi eseguiti comunemente in un sistema Linux

3.2 Selezione dei benchmark

Ho selezionato cinque differenti suite di benchmarking, tentando il più possibile di eliminare overlap nei test:

1. Compilazione del Kernel 2.0.0 (configurazione di default) usando gcc.
2. Whetstone suite versione 10/03/97 (ultima versione di Roy Longbottom).
3. xbench-0.2 (con parametri di esecuzione veloce).
4. UnixBench benchmarks versione 4.01 (risultati parziali).
5. BYTE Magazine's BYTEmark benchmarks beta release 2 (risultati parziali).

Per i test 4 e 5, "(risultati parziali)" significa che non tutti i risultati prodotti da questi benchmark vanno considerati.

3.3 Durata dei test

1. Kernel 2.0.0, compilazione: da 5 a 30 minuti, dipende dalle reali performance del sistema.
2. Whetstone: 100 secondi.
3. Xbench-0.2: < 1 ora.
4. UnixBench benchmarks versione 4.01: approssimativamente 15 minuti.
5. BYTE Magazine's BYTEmark benchmarks: approssimativamente 10 minuti.

3.4 Commenti

Compilazione Kernel 2.0.0:

• Cos'è: È l'unico benchmark applicativo in LBT.
• Il codice è largamente disponibile (p.es. finalmente troverete un uso per i vostri vecchi cd di linux).
• Molti utenti Linux ricompilano il kernel abbastanza spesso, così è una misura significante delle performance generali del sistema
• Il kernel è grosso e gcc usa un bel po' di memoria: ciò attenua il miglioramento che si potrebbe avere grazie alla cache di secondo livello svolgendo piccoli test
• Svolge frequenti operazioni di I/O col disco
• Procedura del test: prendi il sorgente originale di un kernel 2.0.0, compilalo con le opzioni di default (make config e premendo Invio ripetutamente). Il tempo riportato dovrebbe essere il tempo speso nella compilazione p.es. dopo che si è digitato make zImage e non includendo make dep, make clean. Notare che l'architettura di default per il kernel è la i386, perciò se è compilato su un altra architettura, gcc dovrebbe essere impostato come cross-compile, con i386 come architettura di destinazione.
• Risultati: tempo di compilazione in minuti e secondi (per favore, è inutile riportare le frazioni di secondo).

Whetstone:

• Cos'è: misura le prestazioni pure dell'unità in virgola mobile con un corto ciclo. Il sorgente (in C) è abbastanza leggibile ed è molto facile vedere quali operazioni in virgola mobile ne prendono parte.
• Test più corto del LBT :-).
• È un "vecchio classico" test: punti di riferimento sono disponibili, i suoi limiti sono ben conosciuti.
• Procedura del test: il più nuovo sorgente in C dovrebbe essere ottenuto dal sito Aburto. Compilarlo e eseguirlo in modalità doppia precisione. Specificare gcc e -O2 come precompilatore e opzioni del precompilatore.
• Risultati: un indice delle prestazioni dell'unità in virgola mobile in MWIPS.

Xbench-0.2:

• Cos'è: misura le prestazioni dell'X server.
• La misura xStones fornita da xbench è una media pesata di numerosi test riferiti come indice ad una vecchia Sun station con un display in bianco e nero. Hmmm... non è inappuntabile come test dei moderni X server, ma è ancora il miglior strumento che abbia trovato.
• Procedura del test: compilare con -O2. Specifichiamo qualche opzione per una esecuzione più veloce: ./xbench -timegoal 3 > results/name_of_your_linux_box.out. Per avere un punteggio in xStones, dobbiamo eseguire uno script awk; il modo più semplice è di digitare make summary.ms. Controllare il file summary.ms: il punteggio in xStone del sistema è nell'ultima colonna della linea con cui hai specificato il nome della propria macchina durante il test.
• Risultati: le prestazioni di X misurate in xStones.
• Nota: questo test, così com'è è obsoleto. Dovrebbe essere ricodificato

UnixBench versione 4.01:

• Cos'è: misura le prestazioni totali di Unix. Questo test impegnerà le prestazioni di I/O e le prestazioni di multitasking del kernel
• Ho scartato tutti i risultati dei test aritmetici, tenendo solo i risultati relativi al sistema.
• Procedura di test: compilare con -O2. Eseguire con ./Run -1 (esegue ogni test una sola volta). Si troverano i risultati in ./results/report file. Calcolare il significato geometrico di EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS e gli indici di SYSTEM CALL OVERHEAD.
• Risultati: un indice di sistema.

BYTE Magazine's BYTEmark benchmarks:

• Cos'è: fornisce una buona misurazione delle prestazioni del processore. Questo è un estratto dalla documentazione: "questi benchmark hanno la funzione di mostrare il limite superiore teorico di CPU, FPU e architettura di memoria di un sistema. Non possono misurare il video, i dischi o il throughput della rete (questi sono dominio di un'altro set di benchmark). Si dovrebbe, comunque, usare il risultato di questi test come una parte di un processo di misurazione di un sistema, non come tutto il processo."
• Ho scartato i test in virgola mobile dal momento dal momento che il test dei Whetstone è più rappresentativo delle prestazioni in virgola mobile.
• Ho diviso i test interi in due parti: quelli più rappresentativi delle prestazioni di memoria-cache-CPU e i test interi della CPU.
• Procedura del test: compilare con -O2. Eseguire il test con ./nbench > myresults.dat o simile. Poi da myresults.dat, calcolare la media geometrica degli indici della prova STRING SORT, ASSIGNMENT e BITFIELD ; questo è l'indice di memoria ; calcolare la media geometrica degli indici della prova di NUMERIC SORT, IDEA, HUFFMAN and FP EMULATION ; questo è l'indice intero.
• Risultati: un indice di memoria e un indice intero calcolato come spiegato.

3.5 Miglioramenti possibili

La suite ideale di benchmark dovrebbe terminare in qualche minuto, con benchmark sintetici che provino ogni sottosistema separatamente e benchmark applicativi che forniscano risultati per diverse applicazioni. Dovrebbero anche generare automaticamente un rapporto completo e eventualmente spedirlo via e-mail ad un database centrale sul web.

Qui non siamo davvero interessati alla portabilità, ma dovrebbe almeno funzionare su tutte le recenti (> 2.0.0) versioni e sapori (i386, Alpha, Sparc...) di Linux.

Se qualcuno ha un idea circa il benchmarking delle prestazioni di rete in una maniera semplice e facile, con un test breve (meno di 30 minuti per impostarlo ed eseguirlo), per favore mi contatti.

3.6 Modulo LBT

Dopo i test, la procedura di benchmarking non sarebbe completa senza un modulo che descrivesse il setup, che così dovrebbe essere (seguendo le linee guida di comp.benchmarks.faq):

LINUX  BENCHMARKING TOOLKIT REPORT FORM

CPU 
== 
Produttore: 
Modello: 
Frequenza di clock: 
Produttore della scheda madre: 
Modello della sk.madre: 
Chipset della sk.madre: 
Tipo di bus: 
Freq. di clock del bus: 
Cache totale: 
Tipo e velocità della cache: 
SMP (numero di processori): 

RAM 
==== 
Totale: 
Tipo: 
Velocità: 

Disco 
==== 
Produttore: 
Modello: 
Capienza: 
Interfaccia: 
Driver/Settaggi: 

Scheda video: 
=========== 
Produttore: 
Modello: 
Bus:
Tipo di Video RAM: 
Totale di Video RAM: 
Produttore X server: 
Versione X server: 
Scelta del chipset nell'X server: 
Risoluzione/freq di refresh verticale: 
Profondità di colore: 

Kernel 
===== 
Versione: 
Dimensione file di swap:

gcc 
=== 
Versione: 
Opzioni: 
versione libc: 

Note al test
==========

RISULTATI 
======== 
Tempo di compilazione del kernel 2.0.0 
Tempo di compilazione: (minuti e secondi)  
Whetstones: risultati in MWIPS. 
Xbench: risultati in xstones. 
Unixbench Benchmarks 4.01: indice di systema 
BYTEmark: INDEX intero
BYTEmark: INDICE di memoria

Commenti* 
========= 
* Questo campo è incluso per possibili interpretazioni dei risultati,
e come specificato è opzionale. Potrebbe essere la parte più
significativa del proprio report, specialmente se si stanno
effettuando benchmark comparativi.

3.7 Test delle prestazioni della rete

Provare le prestazioni di una rete è un'ardua sfida dal momento che include almeno due macchine, un server ed un client, quindi il doppio del tempo per impostarlo e molte molte variabili da controllare, ecc... Su una rete ethernet, penso che la migliore scelta sarebbe il pacchetto ttcp. (da espandere)

3.8 Test degli SMP (Multi processori simmetrici)

I test degli SMP sono un'altra sfida ed ogni benchmark specificatamente progettato per testare l'SMP avrà un lungo tempo per dimostarsi valido nelle impostazioni della vita reale, dal momento che gli algoritmi che possono prendere vantaggio dall'SMP sono difficili da progettare. Sembra che le ultime versioni del kernel (> 2.1.30 è successive) faranno un multiprocessing "fine-grained". Ma non ho informazioni maggiori in questo momento.

Secondo David Niemi, " ... shell8[parte degli Unixbench 4.01 benchmaks] svolge un buon lavoro nel confrontare combinazioni simili di hardware e sistemi operativi nei modi SMP e UP"