Newsgroup: it.comp.hardware.storage
Titolo: prestazioni di un singolo disco contro 2 dischi in raid 0 (benchmark)

Allora cari amici, finalmente sono riuscito a trovare un po di tempo per 
eseguire questi benedetti benchmark . Ora sapremo (alcuni già lo sanno  ) 
tutta la verità sui reali vantaggi apportati da una configurazione raid 0. 
Come primo test, ho misurato il tempo di installazione del sistema operativo 
Windows Xp:
Singolo disco: 18:40
2 Dischi in Raid 0: 16:45
Il miglioramento quindi con il raid 0 è del 10,3%
E passiamo ora ai test Business Winstone 2004
Single disk
Prima prova: 22,8 (CPU al 60%)
Seconda prova: 23,9 (CPU al 61,4%)
Terza prova: 23,5 (CPU al 61,7%)
Valore medio: 23,4 (Occupazione media CPU: 61%)
2 dischi in raid 0
Prima prova: 23,2 (CPU al 61,4%)
Seconda prova: 23,9 (CPU al 60,9%)
Terza prova: 23,8 (CPU al 61,9%)
Valore medio: 23,63 (Occupazione media CPU: 61,4%)
Il miglioramento è inferiore all'1%, con un overhead della CPU anch'esso 
inferiore all'1%.
Passiamo al multitasking test di Business Winstone 2004.
Single disk
Valore finale #1 2.36 73,4%
Valore finale #2 2.44 2.49 2.18 2.48 75,9%
Valore finale #3 2.44 2.46 2.18 2.51 75,9%
Valore finale medio: 2.41 Occupazione media CPU: 75%
2 dischi in raid 0
1° test 2° test 3° test CPU
Valore finale #1 2.54 2.73 2.29 2.51 79%
Valore finale #2 2.51 2.68 2.3 2.48 78,1%
Valore finale #3 2.53 2.66 2.3 2.52 78,7%
Valore finale medio: 2.526 Occupazione media CPU: 78,6%
L'aumento di performante è pari al 4,8% a fronte di un maggiore carico della 
CPU (3,6% in più).
Ed ora esaminiamo l'ultimo test, il Multimedia Content Creation Winstone 
2004
Single disk
Prima prova: 28,5 (CPU al 83,7%)
Seconda prova: 29,5 (CPU al 86,5%)
Terza prova: 29,4 (CPU al 86,4%)
media: 29,13 (carico medio CPU al 85,53%)
2 dischi in raid 0
Prima prova: 30,2 (CPU al 88,4%)
Seconda prova: 30,4 (CPU al 89%)
Terza prova: 30,3 (CPU al 88,9%)
media: 30,3 (carico medio CPU al 88,76%)
Qui l'incremento di performance è pari al 4% a fronte di un aumento del 
carico della CPU del 3,23%.
Bene, fine dei test. Lascio a voi le conclusioni 

Secondo me è il controller raid della scheda madre che fa schifo!!!
Secondo me non fa nulla in hardware e fa tutto tramite la cpu ecco spiegato
l'aumento di carico.
Poi avrà solo 1 canale che smista sui due dischi, ecco perché non hai alcun
incremento di prestazioni... evedentemente e solo un controller fatto per
darti un raid 1 o 5 per la sicurezza dei dati con poi un notevole carico di
cpu per il calcolo della parità.
Ti rispondo con un mio test fatto tempo fa:
Ho installato linux fedora4 su un p2 350mhz 256ram 
2 dischi ide uno da circa 3g l'altro 4g.
Nessun controller raid.
I due dischi come master su canali differenti
Installando su un solo disco ed eseguendo un controllo con hdparm ottenevo
una velocità di circa 16 Mb/s (non ricordo bene) carico della cpu 
copiando (non spostando) file singolo di 100Mb circa 5% sys
Installandolo in raid 0 software sui due dischi, hdparm mi riportava una
velocità di 24 Mb/s (66% di guadagno, questo dato lo ricordo bene) ma
carico della cpu 10% sys copiando file singolo di 100Mb (Normale, usava due
controller simultaneamente)
Ciao, già che ci sono posto un messaggio su group, un modo per aumentare le
prestazioni di windows su un solo disco senza usare raid.
Prova a fare qualche test con questo metodo, poi mi fai sapere...


Io invece ho ottenuto con winbench99 60000kb/s con la configurazione a 
singolo disco,
e quasi 120000 con la modalità raid 0. Quindi prestazioni quasi doppie. Ma 
ti ricordo che questi tipi di benchmark sono sintetici, e molto 
difficilmente riflettono le reali prestazioni quotidiane. 

> e quasi 120000 con la modalità raid 0. Quindi prestazioni quasi doppie.
Scusa, ma nel test di questa discussione non hai scritto che non hai
ottenuto significativi vantaggi?


Si, ma con la suite Winstone 2004, che è basata su applicativi reali. In 
precedenza avevo eseguito un benchmark sintetico, che non ho riportato in 
questo post.

prima di fare i test dovete assolutamente leggere! che test usate...
se usate dei test che cercano di produrre "carichi reali" allora
quelle % che dici possono essere plausibili...
sebbene come ha detto qualche altro il controller fa pietą :-)
fai un test specifico per il disco...

 ha scritto nel messaggio 
news:43cd5fec$0$1078$4faf...@reader2.news.tin.it...

Scusa non riesco a capire cosa vuoi dire. Io ho specificato nel post il 
benchmark usato.
Ed ho anche fatto un test specifico. Il controller č integrato nell'Nforce 3 
250.
Penso che i risultati siano chiari... 


si certo, ma che test fa quelbenchmark????
fa test specifici sul disco? SeekTime...? Transfer Rate? ....etc...
oppure fa test che simulano l'utilizzo del disco in modo da simulare
un utilizzo del disco in cui si hanno  % di transfer rate % di seek time.. 
letture file ...
sono due test completamete diversi.
in uno si valutano le potenzialità del disco e delle testine in modo fisico 
mentre nell'altro test si valutano poi
come queste potenzialità aggiungono prestazioni in un utilizzo "normale" del 
disco...
quindi nel secondo caso le % relative sono più basse di quel che si possa 
pensare anche con dischi molto performanti,
perchè ci sono in gioco tutti i fattori ed ogni fattore non può essere 
trascurato.
non so se mi son spiegato?
ripeto:
un conto è etstare un disco attraverso un funzionamento più realitstico di 
lettura e scrittura dati,
un conto è tesare una lettura casuale di dati o una lettura di nu file 
grande tanto per vederne transfer rate etc...
quando installi un disco sotto NT sotto XP etc.. le letture e scritture 
hanno una certa coerenza...
e i test che tengono conto di questo danno spesso % di prestazioni più 
basse...
eppure il disco ha un alto transfer rate ad esempio... ma succede che ha un 
alto seek time...
e avolte ci son dischi con basso trasfer rate ma con alto seek time...
insomma  iparametri son tanti.
il succo di tutta questa storia?Non si può lavorare solo su di un parametro 
fisico/hardware del disco,
bisogna lavorare un po' su tutti o sul parametro che realmente fa da collo 
bottiglia...
mi si scusi la spiegazione un po' semplicistica :-)