View Full Version : Disco SCSI Ultra320 più lento di un IDE ???
Allora, il contesto è:
Disco Fujitsu MAW3073NP 73Gb SCSI Ultra320 10.000 rpm
Controller Adaptec 29160 su PCI 32bit
Il disco IDE è un Hitachi Deskstar 40Gb 7.200 rpm
Ho fatto qualche test con HDtach per verificare se ci fossero problemi con il controller inserito in un normale slot PCI a 32bit anzichè 64, o per il fatto che il controller supporta lo standard Ultra160 mentre il disco è Ultra320, ma non mi pare di rilevare nulla di anomalo: il transfer rate segna 107 Mb/s (quindi vicino al limite del bus PCI) mentre l'average read del disco segna 72 Mb/s. L'occupazione media di CPU è sull'8%.
Il fatto è che il caricamento di Windows è sensibilmente più veloce dal disco SCSI, così come la copia di un file di 700 Mb sul disco stesso (73 sec dell'IDE contro i 45 dello SCSI).
Quello che mi lascia perplesso sono invece i risultati a confronto sull'utilizzo di un database SQL con Firebird. Senza scendere nei dettagli di tutte le prove effettuate, posso solo dire che una banale istruzione di aggiornamento su un database abbastanza grosso (700.000 record) impiega 9 secondi sul disco IDE e 40 su quello SCSI. Come è possibile???
Alla fine il motivo per cui ho preso questo disco/controller è per velocizzare l'utilizzo di un'applicazione che accede a un database molto grande, ma mi ritrovo ad attendere 4 minuti e mezzo utilizzando il disco SCSI mentre la stessa operazione, lanciando il programma dal disco IDE, ne impiega 2 e mezzo!!!
La questione è parecchio strana, quali valori di Random Access ti fornisce il test per i due dischi?
- CRL -
Ecco, perdonami ma sono stato fuori nel week-end:
http://img89.imageshack.us/img89/6430/hdtach2le.th.png (http://img89.imageshack.us/my.php?image=hdtach2le.png)
In effetti la questione è molto strana, tra i due dischi ci dovrebbe essere un abisso a livello di prestazioni... Tra l'altro questa coppia Controller + Disco SCSI è stata provata su più sistemi diversi, anche in diversi esemplari (non solo quelli che ho io), ed ha sempre fornito risultati deludenti rispetto a un banalissimo disco IDE!
L'unico aspetto positivo, che non mi sarei aspettato da un disco a 10k rpm, è la silenziosità del Fujitsu in idle.
Le prestazini di quel disco sono eccellenti, dal test risulta tutto OK.
Dove stava il s.o. quando hai fatto le prove?
- CRL -
Nel frattempo ho trovato questo:
http://support.microsoft.com/?kbid=308219
http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html
Il secondo link in particolare è molto interessante. Pare che ci sia qualche problema in Windows XP che influisce sulle prestazioni dei dischi SCSI. Se qualcuno ne sa qualcosa si faccia avanti! Nel frattempo i miei test sull'utilizzo di database SQL continuano a dare risultati sconfortanti e a vedere il disco IDE nettamente in testa...
Le prestazini di quel disco sono eccellenti, dal test risulta tutto OK.
Dove stava il s.o. quando hai fatto le prove?
Nel caso del benchmark, era avviato dallo SCSI.
Il S.O. è installato su entrambi i dischi, ma avviando sia dall'uno che dall'altro, i risultati sono identici come prestazioni nell'utilizzo dell'applicazione. Non ho invece provato ad eseguire HDtach avviando Windows dal disco IDE
Alla fine sono venuto a capo della situazione! :D
Se ho ben capito, in passato c'era in Windows 2000 e XP un bug che faceva in modo che le richieste di scrittura della cache sul disco (FUA - Force Unit Access) venissero beatamente ignorate. In questo modo la cache Write Back dei dischi SCSI era sempre abilitata, a prescindere dalle richieste effettuate dalle applicazioni, il che si ripercuoteva positivamente sulle prestazioni ma alquanto negativamente sulla sicurezza dei dati, visto che in nessun caso si poteva avere la certezza che i dati fossero immediatamente scritti sul mezzo fisico.
Con il SP3 di Windows 2000 e il SP1 di XP, questo bug è stato risolto; di conseguenza molti utenti si sono resi conto di un forte decadimento delle prestazioni dei dischi SCSI. Chiaramente ciò è dovuto al fatto che, con la soluzione del bug, le richieste di flushing della cache o di scrittura Write Through (senza uso della cache) ora vengono correttamente gestite da Windows. Ciò è particolarmente evidente nel momento in cui "il computer esegue molte piccole operazioni di lettura/scrittura", così come Microsoft stessa dichiara in questo controverso articolo (KB 308219): http://support.microsoft.com/?kbid=308219
Notare che questo articolo è aggiornato di recente (31 marzo 2006), ma che la soluzione suggerita da Microsoft ("Per risolvere il problema, procurarsi l'ultimo Service Pack per Windows XP") non è affatto efficace! Difatti con il Service Pack 2 di XP (o idem con il SP4 di Win2k), il bug non c'è più, le richieste di gestione della cache dei dischi SCSI vengono gestite correttamente, quindi le operazioni che coinvolgono molti piccoli file (o molte letture/scritture di piccoli blocchi) effettuate in modalità write-through sono lentissime!
Per farsi un'idea pratica della situazione e verificare gli effetti di tutto ciò sul proprio sistema, si può utilizzare ATTO Disk Benchmark, scaricabile da qui: http://members.home.nl/rvandesanden/ATTO%20benchmark.html
Con questo bench risulta evidente la scarsità di prestazioni in scrittura su blocchi di piccole dimensioni (linee rosse in alto).
http://img232.imageshack.us/img232/703/attosenzacache1kx.th.png (http://img232.imageshack.us/my.php?image=attosenzacache1kx.png)
Questa è esattamente la mia situazione, che nella pratica si manifesta in forti rallentamenti, a confronto con un normale disco IDE, nell'esecuzione di operazioni intensive su un database SQL.
Ora pare che alla Microsoft si siano accorti di tutto ciò, e abbiano cercato di porvi rimedio. A tal proposito date un'occhiata qui (KB 811392): http://support.microsoft.com/default.aspx?scid=kb;en-us;811392
Si sono quindi inventati un'utility dskcache (distribuita solo dietro richiesta al supporto tecnico) che in pratica "ripristina il bug" o, per meglio dire, abilita in ogni caso la cache Write Back, chiamando tutto ciò "Power Protected Write Cache". Power Protected sta per: "sò fatti tuoi se abiliti la cache e poi manca la corrente, quindi vedi di procurarti un gruppo di continuità".
In ogni caso gli effetti di questa utility, una volta abilitata la Power Protected Disk Cache sui dischi SCSI con il comando "dskcache +p /s", sono notevoli e rappresentano esattamente la soluzione ai problemi di lentezza che avevo rilevato.
Questo è il risultato del benchmark ATTO dopo aver applicato la patch:
http://img145.imageshack.us/img145/1226/attoconcache1qr.th.png (http://img145.imageshack.us/my.php?image=attoconcache1qr.png)
Se non vi va di contattare il supporto Microsoft per ottenere l'utility dskcache, potete cercare in questo thread il file Q811392.zip: http://forums.storagereview.net/index.php?showtopic=8865&st=0
Altre fonti interessanti da cui ho tratto le informazioni sono:
http://searchstorage.techtarget.com/tip/1,289483,sid5_gci919227,00.html
http://faq.storagereview.com/tiki-index.php?page=XpScsiProblems
Fatemi sapere se qualcun altro ha lo stesso problema.
Ciao!
Innanzitutto ti ringrazio per aver condiviso tutto questo lavoro, sarà utilissimo a molti, e lo proverò io stesso con i miei, anche se non a breve termine.
Il discorso sicurezza è in realtà meno importante di quanto si possa pensare, se non erro Marco71 mi disse che le versioni di windows con Kernel NT, cioè la 2K e XP, scrivono i metadati dalla cache sul disco ogni 0,5sec, che è un tempo lungo rispetto ai tempi di smaltimento dei comandi, ma molto breve rispetto ai tempi umani di "percezione". Questo vuol dire che se salta la luce perdiamo solo ciò che abbiamo salvato nell'ultimo mezzo secondo, se l'abbiamo fatto, ma essendo questo tempo così breve l'effetto è che se salvi e salta la luce in quel momento, avrai comunque il dubbio se hai fatto in tempo o no, a prescindere da questo mezzo secondo, e dalla politica della cache.
In aggiunta sottolineo come tutti i dischi IDe e SATA sono per default con write back, e quindi utilizzano la cache in scrittura da soli automaticamente, solo che nessuno lo sa e se ne preoccupa, proprio perchè i tempi di ritardo sono di mezzo secondo.
- CRL -
Si, è bene precisare che i dischi IDE non sono e non saranno affetti da questo problema per la natura stessa del protocollo che non prevede l'impostazione di comandi particolari per gestione della cache, come invece accade per lo SCSI.
Qualcuno invece dice che i SATA II, man mano che questo protocollo si avvicina ed assomiglia allo SCSI, potrebbero già ora manifestare gli stessi problemi...
Faccio caso solo ora che il disco è un 10K, e questo mi sorprende moltissimo, fa 90MB/sec di transfer!
Che io sappia è di gran lunga il disco SCSI 10K a transfer maggiore, non credevo che fossimo arrivati a tanto...
- CRL -
Foglia Morta
04-04-2006, 13:48
grazie Atanor , intanto scarico e poi testerò :D
@CRL gli Atlas V hanno un tranfser di 89MB/SEC , ancora non li ho installati , a lungo termine lo farò :D
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.