Avanti Indietro Indice

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:

Whetstone:

Xbench-0.2:

UnixBench versione 4.01:

BYTE Magazine's BYTEmark benchmarks:

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"


Avanti Indietro Indice

Hosting by: hurra.com
Generated: 2007-01-26 17:56:17