  Linux Benchmarking HOWTO
  di Andr D. Balsa, andrewbalsa@usa.net
  v0.12, 15 agosto 1997

  Il Linux Benchmarking HOWTO discute alcune questioni relative al
  benchmarking ("misura delle prestazioni") di sistemi Linux e presenta
  un semplice strumento di benchmarking ed un modulo a questo associato
  che consente di fornire informazioni significative per il benchmarking
  in un paio d'ore. Probabilmente aiuter anche a diminuire la quantit
  di articoli inutili in comp.os.linux.hardware ...  Traduzione di Gian
  luca Pecoraro (atahualpa@altavista.net).
  ______________________________________________________________________

  Indice Generale


  1. Introduzione
     1.1 Perch il benchmarking  cos importante?
     1.2 Considerazioni non valide per il benchmarking

  2. Procedure di benchmarking e interpretazione dei risultati
     2.1 Capire le scelte di benchmarking
        2.1.1 Benchmark sintetici contro applicazioni
        2.1.2 Benchmark di alto livello contro quelli di basso livello
     2.2 Benchmark standard disponibili per Linux
     2.3 Collegamenti e riferimenti

  3. The Linux Benchmarking Toolkit (LBT)
     3.1 Razionale
     3.2 Selezione dei benchmark
     3.3 Durata dei test
     3.4 Commenti
        3.4.1 Compilazione Kernel 2.0.0:
        3.4.2 Whetstone:
        3.4.3 Xbench-0.2:
        3.4.4 UnixBench versione 4.01:
        3.4.5 BYTE Magazine's BYTEmark benchmarks:
     3.5 Miglioramenti possibili
     3.6 Modulo LBT
     3.7 Test delle prestazioni della rete
     3.8 Test degli SMP (Multi processori simmetrici)

  4. Esempi di esecuzione e risultati
  5. Trappole e inesattezze del benchmarking
     5.1 Paragonando mele e arance
     5.2 Informazioni incomplete
     5.3 Hardware/software proprietario
     5.4 Rilevanza

  6. FAQ (Domande Frequenti)
  7. Copyright, riconoscimenti e varie
     7.1 Come  stato scritto questo documento:
     7.2 Copyright
     7.3 Nuove versioni di questo documento
     7.4 Commenti e critiche
     7.5 Riconoscimenti
     7.6 Disclaimer
     7.7 Marchi registrati


  ______________________________________________________________________

  11..  IInnttrroodduuzziioonnee



  _"_W_h_a_t _w_e _c_a_n_n_o_t _s_p_e_a_k _a_b_o_u_t _w_e _m_u_s_t _p_a_s_s _o_v_e_r _i_n _s_i_l_e_n_c_e_._"

       _L_u_d_w_i_g _W_i_t_t_g_e_n_s_t_e_i_n _(_1_8_8_9_-_1_9_5_1_)_, _f_i_l_o_s_o_f_o _a_u_s_t_r_i_a_c_o


  Benchmarking significa mmiissuurraarree la velocit con la quale un computer
  esegue un processo, in una maniera tale da consentire il confronto tra
  differenti combinazioni di hardware e software.  Ci nnoonn include la
  facilit, l'estetica, considerazioni ergonomiche o qualsiasi altro
  giudizio soggettivo.

  Il Benchmarking  un processo tedioso e ripetitivo e necessita
  dell'attenzione ai dettagli. Molto spesso i risultati non sono quelli
  che ci si aspettava, e sono soggetto di interpretazione (che
  attualmente pu essere la parte pi importante di una procedura di
  benchmarking).

  Infine il benchmarking implica fatti e dati, non opinioni e
  approssimazioni.


  11..11..  PPeerrcchh iill bbeenncchhmmaarrkkiinngg  ccooss iimmppoorrttaannttee??


  Oltre alle ragioni spiegate nel BogoMips Mini-HOWTO (sezione 7,
  paragrafo 2), ci si trova a volte a confrontarsi con un budget
  limitato e un minimo di prestazioni richieste per il suo sistema
  Linux. In altre parole, quando ci si pongono le seguenti domande:

    Come massimizzo le prestazioni per un dato budget?

    Come riduco i costi per un dato livello minimo di prestazioni?

    Come ottengo il miglior rapporto prezzo/prestazioni (entro un dato
     budget o una data richiesta di prestazioni?)

  Si dovr esaminare, confrontare e/o produrre benchmark. Minimizzare i
  costi senza un tetto minimo di prestazioni richiesto di solito implica
  il mettere assieme una macchina con rimasugli (quel vecchio 386SX-16
  che sta da qualche parte nel garage andr bene) e non richiede
  benchmark, e massimizzare le prestazioni senza un limite di costi non
   una situazione realistica (a meno che non si voglia mettere un
  sistema Cray nel proprio soggiorno - gli alimentatori rivestiti in
  pelle attorno sembrerebbero simpatici, no?)

  Il benchmarking di per se  senza senso, una perdita di tempo e soldi;
  ha solo senso quando  parte di un processo di decisione, p.es. se si
  deve fare una scelta tra due o pi alternative.

  Di solito un altro parametro nel processo di decisione  il ccoossttoo, ma
  potrebbe anche essere la disponibilit, il servizio, la compatibilit,
  decisioni strategiche o altre caratteristiche misurabili e razionali
  di un computer. Quando si confrontano, p.es. le prestazioni di
  differenti versioni del kernel di linux, la ssttaabbiilliitt  quasi sempre
  pi importante della velocit.


  11..22..  CCoonnssiiddeerraazziioonnii nnoonn vvaalliiddee ppeerr iill bbeenncchhmmaarrkkiinngg


  Spesso si leggono nei newsgroup e nelle mailing list, sfortunatamente:

  1. Reputazione del costruttore (non misurabile e senza senso).

  2. Quote di mercato del costruttore (senza senso e irrilevanti).

  3. Parametri irrazionali (p.es. la superstizione o il pregiudizio:
     compreresti un processore etichettato 171717ZAP e colorato di
     rosa?)

  4. Valori percepiti (senza senso, non misurabili e irrazionali).

  5. Presenza di una forte campagna pubblicitaria: questo  uno dei
     peggiori, penso. Io personalmente sono cresciuto con i logo "XXX
     inside" o "kkkkkws compatibile" (ora "aaaaaPowered  entrato a far
     parte della truppa - chi sar il prossimo ?). A mio modesto avviso,
     i miliardi di dollari spesi in queste campagne sarebbero meglio
     utilizzati dai team di ricerca nel progetto di processori nuovi,
     pi veloci, (economici :-) senza-bug . Nessuna massiccia campagna
     pubblicitaria potr rimuovere un bug nel coprocessore in virgola
     mobile di un nuovo processore che hai appena montato sulla tua
     scheda madre, ma il cambio con un processore riprogettato lo
     farebbe.

  6. Le opinioni del tipo "Tu hai per quello che paghi" sono solo
     quello: opinioni. Fornite i fatti per favore.


  22..  PPrroocceedduurree ddii bbeenncchhmmaarrkkiinngg ee iinntteerrpprreettaazziioonnee ddeeii rriissuullttaattii



  Qualche raccomandazione semi-ovvia

  1. Prima di tutto, iiddeennttiiffiiccaarree ii pprroopprrii oobbiieettttiivvii nneell bbeenncchhmmaarrkkiinngg.
     Cosa si sta esattamente tentando di testare? In che modo il
     processo di benchmarking ci aiuter nel prendere una decisione?
     Quanto tempo e risorse si  intenzionati ad impiegare nei propri
     sforzi di benchmarking?

  2. UUssaarree ssttrruummeennttii ssttaannddaarrdd. Usare una versione recente ma stabile del
     kernel, le attuali gcc e libc ed un banco di test standard. In
     breve usare l'LBT (vedere pi avanti)

  3. Dare una ccoommpplleettaa ddeessccrriizziioonnee del setup (vedere il modulo LBT pi
     avanti).

  4. Provare a iissoollaarree uunnaa ssiinnggoollaa vvaarriiaabbiillee. Il Benchmark comparativo 
     pi informativo del benchmark "assoluto"..  NNoonn lloo rriippeetteerr mmaaii
     aabbbbaassttaannzzaa..

  5. VVeerriiffiiccaarree ii pprroopprrii rriissuullttaattii. Fare i propri benchmark pi di una
     volta e verificare le variazioni nei risultati, se ce ne sono.
     Variazioni inspiegate invalideranno i risultati.

  6. Se si pensa che i propri sforzi nel benchmarking produrrano
     informazioni utili, ccoonnddiivviiddeerrllee con la comunit Linux in una
     maniera pprreecciissaa e ccoonncciissaa.

  7. Per favore ccii ssii ddiimmeennttiicchhii ddeeii BBooggooMMiippss. Mi sono ripromesso di
     implementare un giorno un ASIC davvero veloce con il ciclo dei
     BogoMips dentro. Poi vedremo quello che vedremo!



  22..11..  CCaappiirree llee sscceellttee ddii bbeenncchhmmaarrkkiinngg


  22..11..11..  BBeenncchhmmaarrkk ssiinntteettiiccii ccoonnttrroo aapppplliiccaazziioonnii



  Prima di spendere un bel po' di tempo nei processi di benchmarking va
  fatta una scelta di base fra benchmark "sintetici" e "applicazioni"
  benchmark.

  I benchmark sintetici sono spesso progettati per misurare le
  performance di una singola componente di un sistema, di solito
  impiegando questa componente alla sua massima capacit. Un esempio ben
  conosciuto di benchmark sintetico  la WWhheettssttoonnee suite,
  originariamente programmata nel 1972 da Harold Curnow in FORTRAN (o
  era ALGOL?) e ancora largamente usata ai giorni nostri. La suite
  Whetstone misurer le prestazioni dell'unit in virgola mobile di una
  CPU.

  La maggiore critica che pu essere fatta ai benchmark sintetici,  che
  non rappresentano le prestazioni di un sistema nelle situazioni della
  vita reale. Prendiamo ad esempio la suite Whetstone: il ciclo
  principale  molto corto e entrer facilmente nella cache primaria di
  una CPU, tenendo la pipeline dell'unit in virgola mobile
  costantemente riempita in modo tale da esercitare l'FPU alla sua
  massima velocit. Non possiamo davvero criticare la Whetstone suite se
  ricordiamo che  stata programmata pi di 25 anni fa (e le date della
  progettazione risalgono ancora a prima!), ma noi dobbiamo essere
  sicuri di interpretare i suoi risultati con attenzione, quando ci
  troviamo a testare un moderno microprocessore.

  Un altro punto molto importante circa i benchmark sintetici  che, in
  teoria, loro ci possono dire qualcosa rispetto ad uno ssppeecciiffiiccoo
  aspetto del sistema che stiamo provando, indipendentemente da tutti
  gli altri aspetti: un benchmark sintetico per il troughtput di una
  scheda Ethernet pu avere lo stesso o similare risultato che esso sia
  effettuato su un 386SX-16 con 4MB di Ram o su un Pentium 200 MMX con
  64 MB di RAM. Altrimenti, un test potrebbe misurare le prestazioni
  generali della combinazione di CPU/Scheda Madre/Bus/Scheda
  Ethernet/Sottosistema di memoria/DMA: non molto utile dato che il
  cambio del microprocessore causerebbe un impatto molto pi grande
  rispetto al cambio della scheda di rete Ethernet (questo, ovviamente,
  prendendo per scontato che stiamo usando la stessa combinazione di
  kernel e driver, cosa che potrebbe causare una variazione ancora pi
  grande)!

  Infine uno degli errori pi comuni  fare la media di alcuni benchmark
  sintetici e affermare che quella media  una buona rappresentazione
  della vita reale per ogni dato sistema.

  Questo  un commento dei benchmark sull'unit in virgola mobile
  riproposto con il permesso del sito web della Cyrix Corp.:


       _"_U_n_a _u_n_i_t_ _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _(_F_P_U_) _a_c_c_e_l_e_r_a _i_l _s_o_f_t_w_a_r_e _p_r_o_
       _g_e_t_t_a_t_o _p_e_r _u_s_a_r_e _i_l _c_a_l_c_o_l_o _m_a_t_e_m_a_t_i_c_o _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e_:
       _t_i_p_i_c_a_m_e_n_t_e _p_r_o_g_r_a_m_m_i _C_A_D_, _f_o_g_l_i _e_l_e_t_t_r_o_n_i_c_i_, _g_i_o_c_h_i _3_D _e
       _a_p_p_l_i_c_a_z_i_o_n_i _d_i _d_i_s_e_g_n_o_. _F_a_t_t_o _s_t_a_, _c_h_e _o_g_g_i _m_o_l_t_e _t_r_a _l_e
       _p_i_ _p_o_p_o_l_a_r_i _a_p_p_l_i_c_a_z_i_o_n_i _p_e_r _p_c _f_a_n_n_o _u_s_o _d_i _e_n_t_r_a_m_b_e _l_e
       _i_s_t_r_u_z_i_o_n_i _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _e _i_n_t_e_r_e_. _C_o_m_e _r_i_s_u_l_t_a_t_o_, _C_y_r_i_x
       _h_a _s_c_e_l_t_o _d_i _e_n_f_a_t_i_z_z_a_r_e _i_l _"_p_a_r_a_l_l_e_l_i_s_m_o_" _n_e_l_l_a _p_r_o_g_e_t_
       _t_a_z_i_o_n_e _d_e_i _p_r_o_c_e_s_s_o_r_i _6_x_8_6 _p_e_r _v_e_l_o_c_i_z_z_a_r_e _l_e _p_r_e_s_t_a_z_i_o_n_i
       _d_e_i _s_o_f_t_w_a_r_e _c_h_e _m_i_s_c_h_i_a_n_o _q_u_e_s_t_i _d_u_e _t_i_p_i _d_i _i_s_t_r_u_z_i_o_n_i_.



       _I_l _m_o_d_e_l_l_o _d_i _e_c_c_e_z_i_o_n_e _d_e_l _f_l_o_a_t_i_n_g _p_o_i_n_t _x_8_6 _p_e_r_m_e_t_t_e _a_l_l_e
       _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e _d_i _i_n_i_z_i_a_r_e _e _c_o_m_p_l_e_t_a_r_s_i _m_e_n_t_r_e _u_n
       _i_s_t_r_u_z_i_o_n_e _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _ _a_n_c_o_r_a _i_n _e_l_a_b_o_r_a_z_i_o_n_e_. _I_n
       _c_o_n_t_r_a_s_t_o_, _u_n_a _s_e_c_o_n_d_a _i_s_t_r_u_z_i_o_n_e _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _n_o_n _p_u_
       _i_n_i_z_i_a_r_e _l_a _s_u_a _e_s_e_c_u_z_i_o_n_e _m_e_n_t_r_e _u_n_a _p_r_e_c_e_d_e_n_t_e _i_s_t_r_u_z_i_o_n_e
  _ _a_n_c_o_r_a _i_n _e_s_e_c_u_z_i_o_n_e_. _P_e_r _r_i_m_u_o_v_e_r_e _q_u_e_s_t_o _l_i_m_i_t_e _a_l_l_e
  _p_r_e_s_t_a_z_i_o_n_i_, _i_l _6_x_8_6 _p_u_ _s_p_e_c_u_l_a_r_m_e_n_t_e _i_n_i_z_i_a_r_e _f_i_n_o _a _q_u_a_t_
  _t_r_o _i_s_t_r_u_z_i_o_n_i _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _a_l_l_a _F_P_U _n_e_l _c_h_i_p _m_e_n_t_r_e
  _c_o_n_t_i_n_u_a _a_d _i_n_i_z_i_a_r_e _e_d _e_s_e_g_u_i_r_e _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e_. _P_e_r
  _e_s_e_m_p_i_o_, _i_n _u_n_a _s_e_q_u_e_n_z_a _d_i _c_o_d_i_c_e _c_o_n _d_u_e _i_s_t_r_u_z_i_o_n_i _i_n
  _v_i_r_g_o_l_a _m_o_b_i_l_e _(_F_L_T_) _s_e_g_u_i_t_e _d_a _s_e_i _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e _(_I_N_T_)
  _s_e_g_u_i_t_e _d_a _d_u_e _F_L_T_, _i_l _p_r_o_c_e_s_s_o_r_e _6_x_8_6 _p_u_ _i_n_i_z_a_r_e _a_d
  _e_s_e_g_u_i_r_e _t_u_t_t_e _e _d_i_e_c_i _l_e _i_s_t_r_u_z_i_o_n_i _c_o_n _l_'_a_p_p_r_o_p_r_i_a_t_a _u_n_i_t_
  _d_i _e_s_e_c_u_z_i_o_n_e _p_r_i_m_a _a_n_c_o_r_a _d_e_l _c_o_m_p_l_e_t_a_m_e_n_t_o _d_e_l_l_'_e_s_e_c_u_z_i_o_n_e
  _d_e_l _p_r_i_m_o _F_L_T_. _S_e _n_e_s_s_u_n_a _d_e_l_l_e _i_s_t_r_u_z_i_o_n_i _f_a_l_l_i_s_c_e _(_i_l _c_a_s_o
  _t_i_p_i_c_o_)_, _l_'_e_s_e_c_u_z_i_o_n_e _c_o_n_t_i_n_u_a _c_o_n _e_n_t_r_a_m_b_e _l_e _u_n_i_t_ _i_n_t_e_r_a
  _e_d _a _v_i_r_g_o_l_a _m_o_b_i_l_e _c_h_e _c_o_m_p_l_e_t_a_n_o _i_n _p_a_r_a_l_l_e_l_o _l_e
  _i_s_t_r_u_z_i_o_n_i_. _S_e _u_n_o _d_e_g_l_i _F_L_T _f_a_l_l_i_s_c_e _(_c_a_s_o _a_t_i_p_i_c_o_)_, _l_a
  _c_a_p_a_c_i_t_ _d_i _e_s_e_c_u_z_i_o_n_e _s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6 _p_e_r_m_e_t_t_e _c_h_e _l_o
  _s_t_a_t_o _d_e_l _p_r_o_c_e_s_s_o_r_e _s_i_a _r_e_s_t_a_u_r_a_t_o _i_n _u_n_a _m_a_n_i_e_r_a _c_h_e _s_i_a
  _c_o_m_p_a_t_i_b_i_l_e _c_o_n _i_l _m_o_d_e_l_l_o _d_i _e_c_c_e_z_i_o_n_e _d_e_l_l_'_x_8_6_.



       _L_'_e_s_a_m_e _d_e_i _t_e_s_t _d_i _b_e_n_c_h_m_a_r_k _r_i_v_e_l_a _c_h_e _i _b_e_n_c_h_m_a_r_k _s_i_n_
       _t_e_t_i_c_i _d_e_l_l_'_u_n_i_t_ _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _u_s_a_n_o _u_n _'_c_o_d_e _s_t_r_e_a_m_'
       _i_n _p_u_r_a _v_i_r_g_o_l_a _m_o_b_i_l_e _c_h_e _n_o_n _s_i _t_r_o_v_a _n_e_l_l_e _a_p_p_l_i_c_a_z_i_o_n_i
       _d_e_l _m_o_n_d_o _r_e_a_l_e_. _Q_u_e_s_t_o _t_i_p_o _d_i _b_e_n_c_h_m_a_r_k _n_o_n _t_r_a_e _v_a_n_t_a_g_g_i_o
       _d_a_l_l_e _p_o_s_s_i_b_i_l_i_t_ _d_i _e_s_e_c_u_z_i_o_n_e _s_p_e_c_u_l_a_t_i_v_a _d_e_i _p_r_o_c_e_s_s_o_r_i
       _6_x_8_6_. _C_y_r_i_x _c_r_e_d_e _c_h_e _i _b_e_n_c_h_m_a_r_k _n_o_n _s_i_n_t_e_t_i_c_i _b_a_s_a_t_i _s_u_l_l_e
       _a_p_p_l_i_c_a_z_i_o_n_i _d_e_l _m_o_n_d_o _r_e_a_l_e _r_i_f_l_e_t_t_a_n_o _m_e_g_l_i_o _l_e _a_t_t_u_a_l_i
       _p_r_e_s_t_a_z_i_o_n_i _c_h_e _g_l_i _u_t_e_n_t_i _o_t_t_e_r_r_a_n_n_o_. _L_e _a_p_p_l_i_c_a_z_i_o_n_i _d_e_l
       _m_o_n_d_o _r_e_a_l_e _c_o_n_t_e_n_g_o_n_o _f_u_n_z_i_o_n_i _i_n_t_e_r_e _e _a _v_i_r_g_o_l_a _m_o_b_i_l_e
       _m_i_s_t_e_, _e _q_u_i_n_d_i _b_e_n_e_f_i_c_i_e_r_a_n_n_o _d_e_l_l_a _c_a_p_a_c_i_t_ _d_i _e_s_e_c_u_z_i_o_n_e
       _s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6_"


  Cos la recente moda nel benchmarking  di scegliere applicazioni
  comuni ed usare queste per provare le prestazioni di un computer
  completo. Per esempio, SSPPEECC, l'organizzazione no-profit che ha
  progettato le ben conosciute suite di benchmark SPECINT e SPECFP ha
  lanciato un progetto per una nuova suite di benchmark applicativo. Ma
  ancora  molto difficile che certi benchmark commerciali includeranno
  mai codice Linux.

  Ricapitolando, i benchmark sintetici sono validi fino a che si
  capiscono i loro obiettivi e le loro limitazioni. I benchmark
  applicativi rifletteranno meglio le prestazioni di un computer nel suo
  insieme, ma nessuno  disponibile per Linux.


  22..11..22..  BBeenncchhmmaarrkk ddii aallttoo lliivveelllloo ccoonnttrroo qquueellllii ddii bbaassssoo lliivveelllloo


  I benchmark di basso livello misureranno direttamente le prestazioni
  dell'hardware: il clock del processore, i cicli di DRAM e SRAM, il
  tempo medio di accesso del disco rigido, la latenza, il tempo di
  stepping da traccia a traccia, ecc ... Questo pu essere utile nel
  caso si compri un sistema e si vuole vedere con quali componenti 
  stato costruito, ma una maniera migliore di controllare questo sarebbe
  di aprire il case, elencare i numeri di serie di tutti i componenti, e
  poi ottenere le caratteristiche per ogni componente sul web.

  Un altro uso dei benchmark di basso livello  di controllare che il
  driver del kernel sia correttamente configurato per una specifica
  componente hardware: se si hanno le caratteristiche dichiarate dal
  produttore per quel componente si possono confrontare i risultati dei
  benchmark di basso livello con quelle ...

  I benchmark di alto livello tengono maggiormente conto delle
  prestazioni della combinazione di hardware/driver e sistema operativo
  per un aspetto specifico di un sistema, per esempio, le prestazioni di
  input&output, o anche le prestazioni di una singola applicazione
  rispetto alla combinazione di hardware/driver e sistema operativo,
  p.es. un benchmark di Apache su sistemi differenti.

  Ovviamente tutti i benchmark di basso livello sono sintetici. I
  benchmark di alto livello possono essere sintetici o applicativi.


  22..22..  BBeenncchhmmaarrkk ssttaannddaarrdd ddiissppoonniibbiillii ppeerr LLiinnuuxx


  A mio modesto avviso un semplice test che ognuno pu fare
  nell'aggiornare qualsiasi componente del suo sistema Linux  di
  lanciare la compilazione del kernel prima e dopo l'aggiornamento di
  hardware e/o software e confrontare i tempi di compilazione. Se tutte
  le altre condizioni sono tenute costanti allora il test  valido come
  una misura delle prestazioni nella compilazione e si pu essere
  tranquilli nel dire che:

       "Cambiare A in B porta ad un miglioramento delle prestazioni
       di x % nella compilazione del kernel di Linux sotto tale e
       tali condizioni".



  Ne pi, ne meno!

  Dal momento che la compilazione  un processo molto usuale sotto
  linux, e dal momento che esercita molte funzioni che vengono
  esercitate dai normali benchmark (eccetto le prestazioni in virgola
  mobile), esso costituisce un test iinnddiivviidduuaallee abbastanza buono. In
  molti casi, comunque, i risultati da test a test non possono essere
  riprodotti da altri utenti Linux perch ci sono variazioni nelle
  configurazioni hardware/software e cos questo tipo di test non pu
  essere usato come "unit campione" per confrontare sistemi dissimili
  (a meno che non ci accordiamo su un kernel standard da compilare -
  vedi pi avanti).

  Sfortunatamente, non ci sono strumenti di benchmarking specifici per
  Linux, eccetto forse i Byte Linux Benchmarks che sono una versione
  leggermente modificata dei Byte Unix Benchmarks che datano Maggio 1991
  (Trasposizione Linux di Jon Tombs, autori originali Ben Smith, Rick
  Grehan e Tom Yager).

  C' un sito web centrale per i Byte Linux Benchmarks.

  Una versione migliorata e aggiornata dei Byte Unix Benchmarks   stata
  messa assieme da David C.Niemi. Questa  chiamata UnixBench 4.01 per
  evitare confusioni con le versioni precedenti. Questo  ci che David
  scrisse circa i suoi mods:

       _"_G_l_i _o_r_i_g_i_n_a_l_i _e _l_e_g_g_e_r_m_e_n_t_e _m_o_d_i_f_i_c_a_t_i _B_Y_T_E _U_n_i_x _b_e_n_c_h_m_a_r_k_s
       _s_o_n_o _r_o_t_t_i _i_n _u_n _n_u_m_e_r_o _t_a_l_e _d_i _m_o_d_i _c_h_e _f_a_n_n_o _d_i _l_o_r_o _u_n
       _i_n_d_i_c_a_t_o_r_e _s_t_r_a_n_a_m_e_n_t_e _n_o_n _s_t_a_b_i_l_e _d_e_l_l_e _p_e_r_f_o_r_m_a_n_c_e _d_e_l
       _s_i_s_t_e_m_a_. _I_n_t_e_n_z_i_o_n_a_l_m_e_n_t_e _h_o _f_a_t_t_o _s_e_m_b_r_a_r_e _i _m_i_e_i _v_a_l_o_r_i
       _i_n_d_i_c_e _m_o_l_t_o _d_i_f_f_e_r_e_n_t_i _p_e_r _e_v_i_t_a_r_e _c_o_n_f_u_s_i_o_n_i _c_o_n _i _v_e_c_c_h_i
       _b_e_n_c_h_m_a_r_k_s_._"



  David ha messo su una mailing list basata su majordomo per discutere
  del benchmark su Linux e sistemi operativi concorrenti. Per
  partecipare si invii "subscribe bench" nel corpo di un messaggio a
  majordomo@wauug.erols.com <mailto:majordomo@wauug.erols.com>.  Il
  Washington Area Unix User Group  anche in procinto di mettere su un
  Sito Web per i benchmark Linux.

  Inoltre recentemente, Uwe F. Mayer, mayer@math.vanderbilt.edu
  <mailto:mayer@math.vanderbilt.edu> ha portato la BYTE Bytemark suite
  in Linux. Questa  una moderna suite attentamente assemblata da Rick
  Grehan del BYTE Magazine per testare CPU, FPU e memoria su un moderno
  computer (questi sono benchmark strettamente orientati alle
  prestazioni del processore, n l'I/O n le performance del sistema
  sono tenute in conto).

  Uwe ha anche messo online un Sito Web con un database di risultati per
  la sua versione dei Linux BYTEmark benchmarks.

  Mentre si cerca per benchmark sintetici per Linux, si noter che
  sunsite.unc.edu ha disponibili diversi strumenti di benchmarking. Per
  testare la velocit relativa dei server X e delle schede grafiche, la
  suite xbench-0.2 di Claus Gittinger  disponibile da sunsite.unc.edu,
  ftp.x.org e altri siti. Xfree86.org si rifiuta (saggiamente) di
  rendere disponibile o raccomandare alcun benchmark.

  L'XFree86-benchmarks Survey  un sito web con database di risultati di
  x-bench.

  Per il troughput puro I/O dei dischi il programma hdparm (incluso con
  molte distribuzioni, altrimenti disponibile da sunsite.unc.edu)
  misurer la velocit di trasferimento se avviato con le opzioni -t e
  -T. Ci sono molti altri strumenti liberamente disponibili su Internet
  per provare vari aspetti delle prestazioni di un sistema Linux.


  22..33..  CCoolllleeggaammeennttii ee rriiffeerriimmeennttii


  comp.benchmarks.faq di Dave Sill  ancora il punto di riferimento
  standard per il benchmarking. Non  specifico per Linux, ma la lettura
   raccomandata per chiunque si voglia impegnare seriamente nel
  benchmarking.  disponibile da un grande numero di FTP e siti web ed
  elenca 5566 ddiiffffeerreennttii bbeenncchhmmaarrkk, con links agli FTP o siti web che li
  rendono disponibili. Alcuni dei benchmark listati sono commerciali
  (SPEC per esempio).

  Quindi non andr oltre nell'esaminare ognuno dei benchmark menzionati
  in comp.benchmarks.faq, ma c' almeno una suite di basso livello di
  cui voglio parlare: la lmbench suite, di Larry McVoy.  Citando David
  C. Niemi:


       _"_L_i_n_u_s _e _D_a_v_i_d _M_i_l_l_e_r _l_a _u_s_a_n_o _m_o_l_t_o _p_e_r_c_h_ _f_a _m_o_l_t_e _u_t_i_l_i
       _m_i_s_u_r_a_z_i_o_n_i _d_i _b_a_s_s_o _l_i_v_e_l_l_o _e _p_u_ _a_n_c_h_e _m_i_s_u_r_a_r_e _i_l
       _t_h_r_o_u_g_h_p_u_t _d_i _r_e_t_e _e _l_a _l_a_t_e_n_z_a _s_e _s_i _h_a_n_n_o _2 _s_i_s_t_e_m_i _d_a
       _t_e_s_t_a_r_e_.


  Un Sito FTP piuttosto completo per benchmark lliibbeerraammeennttee disponibili 
  stato messo su da Alfred Aburto. La Whetstone suite usata nell'LBT pu
  essere trovata a questo sito.

  C' una FFAAQQ iinn ppii ppaarrttii ddii EEuuggeennee MMiiyyaa che viene postata regolarmente
  su comp.benchmarks;  un eccellente punto di riferimento.


  33..  TThhee LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT))


  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3..11..  RRaazziioonnaallee

  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 ssiinntteettiiccoo dovrebbe impiegare il relativo
     sottosistema alla sua massima capacit.

  6. I risultati dei benchmark ssiinntteettiiccii nnoonn 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3..22..  SSeelleezziioonnee ddeeii bbeenncchhmmaarrkk


  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..33..  DDuurraattaa ddeeii tteesstt


  1. Kernel 2.0.0, compilazione: da 5 a 30 minuti, dipende dalle rreeaallii
     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3..44..  CCoommmmeennttii


  33..44..11..  CCoommppiillaazziioonnee KKeerrnneell 22..00..00::


    CCooss''::  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
     nnoonn 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.

    RRiissuullttaattii:: tempo di compilazione in minuti e secondi (per favore, 
     inutile riportare le frazioni di secondo).



  33..44..22..  WWhheettssttoonnee::


    CCooss'':: 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.
     RRiissuullttaattii:: un indice delle prestazioni dell'unit in virgola
     mobile in MWIPS.



  33..44..33..  XXbbeenncchh--00..22::


    CCooss'':: 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.

    RRiissuullttaattii:: le prestazioni di X misurate in xStones.

    Nota: questo test, cos com'  obsoleto. Dovrebbe essere
     ricodificato



  33..44..44..  UUnniixxBBeenncchh vveerrssiioonnee 44..0011::


    CCooss'':: 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.

    RRiissuullttaattii:: un indice di sistema.


  33..44..55..  BBYYTTEE MMaaggaazziinnee''ss BBYYTTEEmmaarrkk bbeenncchhmmaarrkkss::


    CCooss'':: fornisce una buona misurazione delle prestazioni del
     processore. Questo  un estratto dalla documentazione: _"_q_u_e_s_t_i
     _b_e_n_c_h_m_a_r_k _h_a_n_n_o _l_a _f_u_n_z_i_o_n_e _d_i _m_o_s_t_r_a_r_e _i_l _l_i_m_i_t_e _s_u_p_e_r_i_o_r_e _t_e_o_r_i_c_o
     _d_i _C_P_U_, _F_P_U _e _a_r_c_h_i_t_e_t_t_u_r_a _d_i _m_e_m_o_r_i_a _d_i _u_n _s_i_s_t_e_m_a_. _N_o_n _p_o_s_s_o_n_o
     _m_i_s_u_r_a_r_e _i_l _v_i_d_e_o_, _i _d_i_s_c_h_i _o _i_l _t_h_r_o_u_g_h_p_u_t _d_e_l_l_a _r_e_t_e _(_q_u_e_s_t_i _s_o_n_o
     _d_o_m_i_n_i_o _d_i _u_n_'_a_l_t_r_o _s_e_t _d_i _b_e_n_c_h_m_a_r_k_)_. _S_i _d_o_v_r_e_b_b_e_, _c_o_m_u_n_q_u_e_, _u_s_a_r_e
     _i_l _r_i_s_u_l_t_a_t_o _d_i _q_u_e_s_t_i _t_e_s_t _c_o_m_e _u_n_a _p_a_r_t_e _d_i _u_n _p_r_o_c_e_s_s_o _d_i
     _m_i_s_u_r_a_z_i_o_n_e _d_i _u_n _s_i_s_t_e_m_a_, _n_o_n _c_o_m_e _t_u_t_t_o _i_l _p_r_o_c_e_s_s_o_._"

    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'iinnddiiccee ddii mmeemmoorriiaa ; calcolare la
     media geometrica degli indici della prova di NUMERIC SORT, IDEA,
     HUFFMAN and FP EMULATION ; questo  l'iinnddiiccee iinntteerroo.

    RRiissuullttaattii:: un indice di memoria e un indice intero calcolato come
     spiegato.



  33..55..  MMiigglliioorraammeennttii ppoossssiibbiillii

  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3..66..  MMoodduulloo LLBBTT

  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3..77..  TTeesstt ddeellllee pprreessttaazziioonnii ddeellllaa rreettee

  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3..88..  TTeesstt ddeeggllii SSMMPP ((MMuullttii pprroocceessssoorrii ssiimmmmeettrriiccii))

  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, _" _._._. _s_h_e_l_l_8[parte degli Unixbench 4.01
  benchmaks] _s_v_o_l_g_e _u_n _b_u_o_n _l_a_v_o_r_o _n_e_l _c_o_n_f_r_o_n_t_a_r_e _c_o_m_b_i_n_a_z_i_o_n_i _s_i_m_i_l_i
  _d_i _h_a_r_d_w_a_r_e _e _s_i_s_t_e_m_i _o_p_e_r_a_t_i_v_i _n_e_i _m_o_d_i _S_M_P _e _U_P_"


  44..  EEsseemmppii ddii eesseeccuuzziioonnee ee rriissuullttaattii

  L'LBT  stato eseguito sulla mia macchina di casa, un sistema Linux di
  classe Pentium con il quale ho scritto questo HOWTO. Qui c' il modulo
  di report LBT per il mio sitema


  LINUX  BENCHMARKING TOOLKIT REPORT FORM



  CPU



  ==



  Produttore: Cyrix/IBM



  Modello: 6x86L P166+



  Frequenza di clock: 133 MHz



  Produttore scheda madre: Elite Computer Systems (ECS)



  Sk. madre: P5VX-Be



  Chipset: Intel VX



  Tipo di bus: PCI



  Frequenza di clock del bus: 33 MHz



  Cache totale: 256 KB



  Cache tipo/velocit: Pipeline burst 6 ns



  SMP (numero di processori): 1



  RAM



  ====



  Totale: 32 MB



  Tipo: EDO SIMMs



  Velocit: 60 ns

  Disco



  ====



  Produttore: IBM



  Modello: IBM-DAQA-33240



  Grandezza: 3.2 GB



  Interfaccia: EIDE



  Driver/Settaggi: Bus Master DMA modo 2



  Scheda video



  ===========



  Produttore: Generica S3



  Modello: Trio64-V2



  Bus: PCI



  Tipo Video RAM: EDO DRAM



  Totale Video RAM: 2 MB



  Produttore X server: XFree86



  Versione X server: 3.3



  Scelta chipset dell'X server: S3 accellerato

  Risoluzione/rinfresco verticale: 1152x864 @ 70 Hz



  Profondit di colore: 16 bit



  Kernel



  =====



  Versione: 2.0.29



  File di swap: 64 MB



  gcc



  ===



  Versione: 2.7.2.1



  Opzioni: -O2



  versione libc: 5.4.23



  Note del test



  ==========



  Carico molto basso. I seguenti risultati sono stati ottenuti abilitando alcune delle speciali features del Cyrix/IBM 6x86
  abilitate con il programma setx86: fast ADS,  fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem.



  RISULTATI



  ========



  Kernel Linux 2.0.0 Tempo di compilazione: 7m12s



  Whetstones: 38.169 MWIPS.



  Xbench: 97243 xStones.



  BYTE Unix Benchmarks 4.01 INDICE di sistema: 58.43



  BYTEmark integri INDICE: 1.50



  BYTEmark INDICE memoria: 2.50



  Commenti



  =========



  Questo  un sistema molto stabile con prestazioni omogenee, ideale per l'uso di casa e/o lo sviluppo in Linux. Riporter al pi presto i risultati con un processore 6x86MX appena ne avr uno fra le mani!



  55..  TTrraappppoollee ee iinneessaatttteezzzzee ddeell bbeenncchhmmaarrkkiinngg


  Dopo aver messo insieme questo HOWTO ho iniziato a comprendere come le
  parole "trappole" e "inesattezze" siano cos spesso associate al
  benchmarking...


  55..11..  PPaarraaggoonnaannddoo mmeellee ee aarraannccee


  O dovrei dire Apple e PC? Questa  una disputa cos vecchia e ovvia
  che non andr avanti nei dettagli. Dubito che il tempo che impieghi
  Word a caricarsi su un Mac confrontato con un medio Pentium sia la
  misura reale di qualcosa. Lo stesso vale per il confronto tra il tempo
  di boot di Linux e Windows NT, ecc ... Provare a confrontare il pi
  possibile macchine identiche con una singola modifica.


  55..22..  IInnffoorrmmaazziioonnii iinnccoommpplleettee


  Un singolo esempio illustrer questo errore molto comune. Spesso si
  legge in comp.os.linux.hardware le seguenti frasi, o simili: "Ho
  appena montato il processore XYZ a nnn MHz e ora compilare il kernel
  di linux prende solo x minuti" (poni pure XYZ , nnn e x come meglio
  credi). Questo  irritante, perch nessun altra informazione  data,
  ad.es. non sappiamo neanche l'ammontare della RAM, la dimensione dello
  swap, gli altri processi in esecuzione nello stesso momento, la
  versione del kernel, i moduli selezionati, il tipo di hard disk, la
  versione di gcc, ecc...  consigliato di usare il modulo di report LBT
  che utilizza almeno una maschera di raccolta dati standard.


  55..33..  HHaarrddwwaarree//ssooffttwwaarree pprroopprriieettaarriioo


  Un ben conosciuto produttore di processori una volta pubblic i
  risultati dei benchmarks prodotti da una speciale, personalizzata
  versione di gcc. A parte le considerazioni etiche, questi risultati
  erano senza senso, dal momento che il 100% della comunit Linux
  continuerebbe ad usare la versione standard di gcc. Lo stesso vale per
  l'hardware proprietario. Il Benchmarking  molto pi utile quando si
  rapporta a hardware comune e software libero (nel significato GNU/GPL
  di libero).


  55..44..  RRiilleevvaannzzaa


  Stiamo parlando di Linux, giusto? Cos ci dobbiamo scordare dei
  benchmark prodotti su altri sistemi operativi (questo  un caso
  speciale della trappola "Confrontare mele e arance" spiegata prima).
  Allo stesso modo, se si  intenzionati a testare le prestazioni di un
  server Web, nnoonn citare le prestazioni dell'unit in virgola mobile, o
  altre informazioni irrilevanti. In molti casi meno  meglio. Allo
  stesso modo, nnoonn c' bisogno di menzionare gli anni del tuo gatto, il
  tuo stato d'animo mentre stavi effettuando il test, ecc...


  66..  FFAAQQ ((DDoommaannddee FFrreeqquueennttii))


     DD11..
        C' un qualsiasi indice di merito per i sistemi Linux?

     AA:: No, fortunatamente nessuno  ancora venuto fuori con una
        misurazione Lhinuxstone (tm). E se ce ne fosse uno, non avrebbe
        molto senso: i sistemi Linux sono usati per tanti differenti
        compiti, dal server web pesantemente caricato alla workstation
        grafica per uso individuale. Nessun singolo indice di merito pu
        descrivere le prestazioni di un sistema Linux in differenti
        situazioni.

     DD22..
        Quindi perch non una dozzina di indici riassumenti le
        prestazioni di diversi sistemi Linux?

     AA:: Sarebbe la situazione ideale. Vorrei vedere ci diventare
        realt. Nessun volontario per un LLiinnuuxx BBeenncchhmmaarrkkiinngg PPrroojjeecctt? Con
        un sito web e un database completo e ben progettato?

     DD33..
        ... BogoMips ...?

     AA:: I BogoMips non hanno nniieennttee a che fare con le prestazioni del
        sistema. Leggere il BogoMips Mini-HOWTO.

     DD44..
        Qual  il miglior benchmark per Linux?

     AA:: Dipende da quale aspetto prestazionale di linux si vuole
        misurare. Ci sono differenti benchmark per misurare la rete
        (p.es i transfer rate), i file server (NFS), l'I/O dei dischi,
        le prestazioni sui calcoli in virgola mobile e interi, grafica,
        3D, larghezza di banda della memoria del processore, prestazioni
        CAD, tempo di transazione, prestazioni SQL, prestazioni del
        server Web, prestazioni in tempo reale, prestazioni del CD-ROM,
        prestazioni di Quake (!), ecc ... AFAIK nessuna suite di
        benchmark esiste per linux che supporti tutti questi test.

     DD55..
        Qual  il processore pi veloce sotto Linux?

     AA:: Il pi veloce in quale processo? Se si  molto orientati alla
        masticazione di numeri, un processore Alpha ad alta frequenza di
        clock (600 MHz in su) dovrebbe essere pi veloce di nessun
        altro, dal momento che gli Alpha sono stati progettati proprio
        per fornire questo tipo di prestazioni. Se, dall'altro lato, si
        vuole mettere assieme un server news davvero veloce,  probabile
        che la scelta di un veloce sottosistema di dischi rigidi e molta
        RAM risulter in un migliore aumento di prestazioni che un
        cambio di processore per la stessa somma di $.

     DD66..
        Fammi riformulare l'ultima domanda, allora: c' un processore
        che  il pi veloce per applicazioni generiche?

     AA:: Questa  una domanda trabocchetto ma ha una sola e semplice
        risposta: NNOO. Si pu sempre disegnare un sistema veloce anche
        per applicazioni generiche, indipendentemente dal processore. Di
        solito, restando uguali tutte le altre cose, una pi alta
        frequenza di clock risulter in maggiori prestazioni del sistema
        (e anche pi mal di testa). Tirando fuori un vecchio processore
        a 100Mhz da una motherboard (di solito non) aggiornabile, e
        inserendo dentro la versione a 200Mhz, si dovrebbe sentire una
        grande differenza. Certamente con solo 16 MB di RAM, lo stesso
        investimento sarebbe stato molto pi saggiamente speso in DIMMs
        aggiuntive ...

     DD77..
        Ma allora la frequenza di clock influenza le prestazioni di un
        sistema?

     AA:: Per molti processi, eccetto per i loop NOP vuoti (a proposito,
        questi stanno per essere rimossi dai moderni compilatori
        ottimizzanti), una maggiorazione nella frequenza di clock non
        darebbe un aumento lineare delle prestazioni. Molti piccoli
        programmi che fanno un uso intensivo del processore entrano
        interamente nella cache primaria del processore (la cache L1,
        usualmente 16 o 32K) e avranno un aumento di prestazioni
        equivalente all'aumento della frequenza di clock, ma molti
        "veri" programmi sono molto pi larghi di ci, hanno cicli che
        non entrano nella cache L1, condividono la cache di secondo
        livello (L2) con altri processi, dipendono da componenti esterni
        e daranno un incremento di prestazioni molto minore. Questo 
        perch la cache L1 funziona alla stessa frequenza di clock del
        processore, mentre molte cache di secondo livello e tutti gli
        altri sottosistemi (DRAM per esempio) funzionano in maniera
        asincrona a minore frequenza di clock.

     DD88..
        OK, poi, un ultima domanda su questa questione: qual  il
        processore con il miglior rapporto tra prezzo e prestazioni per
        un uso generico di Linux?

     AA:: Definire un "Linux di uso generico" non  una cosa facile! Per
        ogni particolare applicazione, c' sempre un processore con IL
        MIGLIORE rapporto prezzo/prestazioni in ogni momento, ma cambia
        abbastanza frequentemente cos come i produttori rilasciano
        nuovi processori, cos rispondere Processore XYZ a nnn Mhz
        sarebbe una risposta valida solo in quel momento. Comunque il
        prezzo di un processore  insignificante se paragonato al prezzo
        dell'intero sistema che si sta assemblando. Cos, davvero, la
        questione dovrebbe come si pu massimizzare il rapporto tra
        prezzo e prestazioni di un dato sistema? E la risposta a questa
        domanda dipende fortemente dal minimo di prestazioni richieste
        e/o dal prezzo massimo stabilito per la configurazione che si
        sta considerando. A volte l'hardware comune non soddisfa le
        prestazioni minime richieste e costosi sistemi RISC sarebbero la
        sola alternativa. Per l'uso di casa si raccomanda un sistema
        bilanciato e omogeneo per tutte le prestazioni (ora vai ad
        immaginare che cosa io intendo per bilanciato e omogeneo :-); la
        scelta di un processore  una decisione importante, ma non pi
        che scegliere il tipo di disco fisso e la capacit, il
        quantitativo di RAM, la scheda video, ecc ...

     DD99..
        Quando un aumento delle prestazioni  considerato
        "significativo"?

     AA:: Vorrei rispondere che innanzittutto ogni variazione sotto all'1%
        non  significativa (potrebbe essere descritta come
        "marginale"). Noi umani, difficilmente percepiamo la differenza
        tra due sistemi con un 5% di differenza nel tempo di risposta.
        Certamente alcuni benchmarkers "hard-core" non sono umani e ti
        diranno confrontando un sistema con indici di sistema 65.9 e
        66.5 che il secondo  sicuramente molto pi veloce.

     DD1100..
        Come posso ottenere "significativi" aumenti nelle prestazioni al
        costo minore?

     AA:: Dal momento che molti codici sorgenti per Linux sono disponibili
        gratuitamente, l'esame attento e il ridisegno algoritmico delle
        subroutine chiave potrebbe aumentare in alcuni casi le
        prestazioni. Se ci si trova ad avere a che fare con un progetto
        commerciale e non ci si vuole addentrare profondamente nello
        sviluppo in codice C ssii ddoovvrreebbbbee cchhiiaammaarree uunn ccoonnssuulleennttee LLiinnuuxx.
        Vedere il Consultants-HOWTO.



  77..  CCooppyyrriigghhtt,, rriiccoonnoosscciimmeennttii ee vvaarriiee


  77..11..  CCoommee  ssttaattoo ssccrriittttoo qquueessttoo ddooccuummeennttoo::


  Il primo passo  stato leggere la sezione 4 di "Writing and submitting
  a HOWTO" dell'HOWTO Index di Tim Bynum.

  Non conoscevo assolutamente niente di SGML o LaTeX, ma sono stato
  tentato di usare un pacchetto automatico di generazione dopo aver
  letto i vari commenti sugli SGML-Tools. Comunque inserire i tags
  manualmente in un documento mi ricorda i giorni che assemblai a mano
  un programma monitor da 512 byte per un, ora defunto, processore a
  8bit, cos sono entrato in possesso dei codici sorgenti di LyX, li ho
  compilati, ed ho usato il suo modo LinuxDoc. Combinazione altamente
  raccomandata: LLyyXX ee SSGGMMLL--TToooollss.


  77..22..  CCooppyyrriigghhtt


  The Linux Benchmarking HOWTO is copyright (C) 1997 by Andr D. Balsa.
  Linux HOWTO documents may be reproduced and distributed in whole or in
  part, in any medium physical or electronic, as long as thqs copyright
  notice is retained on all copies. Commercial redistribution is allowed
  and encouraged; however, the author would like to be notified of any
  such distributions.

  All translations, derivative works, or aggregate works incorporating
  any Linux HOWTO documents must be covered under this copyright notice.
  That is, you may not produce a derivative work from a HOWTO and impose
  additional restrictions on its distribution. Exceptions to these rules
  may be granted under certain conditions; please contact the Linux
  HOWTO coordinator at the address given below.

  In short, we wish to promote dissemination of this information through
  as many channels as possible.  However, we do wish to retain copyright
  on the HOWTO documents, and would like to be notified of any plans to
  redistribute the HOWTOs.

  If you have questions, please contact Tim Bynum, the Linux HOWTO
  coordinator, at linux-howto@sunsite.unc.edu via email.


  77..33..  NNuuoovvee vveerrssiioonnii ddii qquueessttoo ddooccuummeennttoo


  Le nuove versioni del Linux Benchmarking-HOWTO saranno depositate su
  sunsite.unc.edu e siti mirror.  Sono disponibili altri formati, come
  una versione Postscript e dvi, nella directory other-formats. Il Linux
  Benchmarking-HOWTO  pure dispononibile per client WWW come Grail, un
  Web browser scritto in Python. Sar pure inviato regolarmente a
  comp.os.linux.answers.


  77..44..  CCoommmmeennttii ee ccrriittiicchhee

  Sono richiesti suggerimenti, correzioni e aggiunte. Si cercano
  contributi e riscontri. Non si cercano flame.

  Posso sempre essere raggiunto a andrewbalsa@usa.net.


  77..55..  RRiiccoonnoosscciimmeennttii


  David Niemi, l'autore della suite Unixbench, ha provato di essere una
  fonte inesauribile di informazioni e di (valide) critiche.

  Voglio anche ringraziare Greg Hankins uno dei maggiori contributori al
  pacchetto SGML-tools, Linus Torvalds e l'intera comunit Linux. Questo
  HOWTO  il mio modo per ringraziare.


  77..66..  DDiissccllaaiimmeerr


  Your mileage may, and will, vary. Be aware that benchmarking is a
  touchy subject and a great time-and-energy consuming activity.


  77..77..  MMaarrcchhii rreeggiissttrraattii


  Pentium e Windows NT sono marchi registrati rispettivamente da Intel e
  Microsoft.

  BYTE e BYTEmark sono marchi registrati da McGraw-Hill, Inc.

  Cyrix e 6x86 sono marchi registrati da Cyrix Corporation.

  Linux non  un marchio registrato, e spero che mai lo sar. :)



