Controller SAS RAID - Dell Perc 5i aka LSI 8408E

[il menne]

Ho trovato un articolo (link ) dove si riporterebbero dichiarazioni di Seagate stessa sugli incrementi prestazionali del 15k.6 rispetto al 15k.5..

In particolare:

"The Cheetah 15K.6 drive lowers idle and operational power requirements from its prior generation - as much as 61 percent in watts/GB - while increasing overall sustained data transfer rates by 28 percent at 164MB/s,- the company said"

[shingo]

Originariamente inviato da Pelvix

Adeso magari (vista l'ora) sparo una cavolata:
sulla mia Rampage, ho la vga 8800 GTX nel primo slot PCI-E @ 16X, il CTR Dell PERC 5 nel secondo slot PCI-E @ 8X, e la Cinergy (scheda Tv digitale) in un PCI-E @ 1x.

Non è che è la Cinergy a causare il collo di bottiglia sul PCI-E?

Devi leggere sul manuale della main come vengono gestite le linee pci-e. E' possibile che inserendo una terza cheda pci vengano segate le linee sul secondo connettore....

[supermario]

Originariamente inviato da Pelvix

Adeso magari (vista l'ora) sparo una cavolata:
sulla mia Rampage, ho la vga 8800 GTX nel primo slot PCI-E @ 16X, il CTR Dell PERC 5 nel secondo slot PCI-E @ 8X, e la Cinergy (scheda Tv digitale) in un PCI-E @ 1x.

Non è che è la Cinergy a causare il collo di bottiglia sul PCI-E?

l'x48 ha abbastanza linee pcie da gestire i tuoi componenti, inoltre se fosse vero quello che dici noteresti un notevole calo di prestazioni nei giochi

[Pelvix]

Ma quello che mi fa strano è che secondo ATTO (che dovrebbe esser affidabile da ciò che ho lettp in giro) ho oltre 680 MB/sec in lettura, poi però vado a spostare un file da 2,8 GB e ci metto 5 minuti

Voglio dire che se ci fosse un collo di bottiglia, dovrebbe esserci anche facendo bench no?

[Pelvix]

Originariamente inviato da Pelvix

Ma quello che mi fa strano è che secondo ATTO (che dovrebbe esser affidabile da ciò che ho lettp in giro) ho oltre 680 MB/sec in lettura, poi però vado a spostare un file da 2,8 GB e ci metto 5 minuti

Voglio dire che se ci fosse un collo di bottiglia, dovrebbe esserci anche facendo bench no?

Posto i miei settaggi del crt, casomai ci fosse qualcosa di sbagliato..

Element Size: 64 kb
Read Policy: No Read Ahead
Write Policy: Write Through

[saverio80]

Originariamente inviato da il menne

Configurazione usata per i test ( fatta al volo )

Array raid0, massima capacità

Stripe: 128k

Read policy: adaptive

Default write policy: write back

IO policy: direct IO

Disk cache policy: enabled

init state: fast

Originariamente inviato da Pelvix

Element Size: 64 kb
Read Policy: No Read Ahead
Write Policy: Write Through

qualcosa non mi torna
comunque perche' read policy non e' su read ahead o adaptative?
in ogni caso 64k e' bassino, sopratutto se utilizzi grossi files, se quello che ti interessa e' manipolare grossi files 128 o 256 sono consigliati

[Pelvix]

Originariamente inviato da saverio80

qualcosa non mi torna
comunque perche' read policy non e' su read ahead o adaptative?
in ogni caso 64k e' bassino, sopratutto se utilizzi grossi files, se quello che ti interessa e' manipolare grossi files 128 o 256 sono consigliati

1- Che cosa non ti torna?
2- 64k è indicato per rendere il SO più reattivo no?
3- Perchè "Read Policy" non va bene come l'ho settato io?

[Marco71]

...come politica di caching in lettura consiglia l'algoritmo "adattivo" nel caso di pattern del flusso dati che il controllore deve analizzare, non conosciuto a priori.
"Read ahead" negli altri casi.
Grazie.

Marco71.

[Marco71]

Originariamente inviato da Pelvix

Posto i miei settaggi del crt, casomai ci fosse qualcosa di sbagliato..

Element Size: 64 kb
Read Policy: No Read Ahead
Write Policy: Write Through

...lasciare in "write through" la politica di aggiornamento dati in scrittura, limitatamente a quando stati facendo esperimenti di benchmarking.
Nella "vita reale" ti consiglio il write back...da utilizzare se in possesso di almeno un U.P.S e/o un battery pack collegato al controllore.
Grazie.

Marco71.

[Marco71]

Originariamente inviato da Pelvix

Ma quello che mi fa strano è che secondo ATTO (che dovrebbe esser affidabile da ciò che ho lettp in giro) ho oltre 680 MB/sec in lettura, poi però vado a spostare un file da 2,8 GB e ci metto 5 minuti

Voglio dire che se ci fosse un collo di bottiglia, dovrebbe esserci anche facendo bench no?

...è una delle conseguenze nell'affidarsi quasi sempre a programmi di benchmarking "sintetici" (ed aggiungo scritti non sempre in modo da adattarsi a sottosistemi di I/O abbastanza esotici, con controllori dotati di caching onboard ecc. ecc.).
Il file da 2.8 GiB è contiguo ?
E.g. di norma utilizzi un buon deframmentatore anche per le unità logiche facenti capo e costituite da più unità fisiche collegate in matrici R.A.I.D ?
Grazie.

Marco71.

[Marco71]

Originariamente inviato da il menne

Ho trovato un articolo (link ) dove si riporterebbero dichiarazioni di Seagate stessa sugli incrementi prestazionali del 15k.6 rispetto al 15k.5..

In particolare:

"The Cheetah 15K.6 drive lowers idle and operational power requirements from its prior generation - as much as 61 percent in watts/GB - while increasing overall sustained data transfer rates by 28 percent at 164MB/s,- the company said"

...confermo tutto quanto...
Seagate ha impiegato testine di scrittura di seconda generazione utilizzanti il sistema di registrazione dei bit "perpendicolare", migliorie nel firmware.
Anche la densità in Gigabit/pollice quadrato è aumentata.
Grazie.

Marco71.

[Pelvix]

Originariamente inviato da Marco71

...lasciare in "write through" la politica di aggiornamento dati in scrittura, limitatamente a quando stati facendo esperimenti di benchmarking.
Nella "vita reale" ti consiglio il write back...da utilizzare se in possesso di almeno un U.P.S e/o un battery pack collegato al controllore.
Grazie.

Marco71.

Io ho sia l' UPS che la batteria tampone del ctr, quindi deduco che sia meglio il settaggio "Write back" per me, giusto?

PS: se cambio il settaggio di "Write" devo reistallare tutto?

[Pelvix]

Originariamente inviato da Marco71

...è una delle conseguenze nell'affidarsi quasi sempre a programmi di benchmarking "sintetici" (ed aggiungo scritti non sempre in modo da adattarsi a sottosistemi di I/O abbastanza esotici, con controllori dotati di caching onboard ecc. ecc.).
Il file da 2.8 GiB è contiguo ?
E.g. di norma utilizzi un buon deframmentatore anche per le unità logiche facenti capo e costituite da più unità fisiche collegate in matrici R.A.I.D ?
Grazie.

Marco71.

Ma ATTO non è uno dei più affidabili?
Il file da 2,8 GB è una iso.
Ho installato Diskeeper 2008 Pro Premier

[Marco71]

Originariamente inviato da il menne

Il paragone è fatto in modo grossolano .... e solo basato sul transfer rate.... per quanto inerente l'access time, l'affidabilità, l'uso in non single-user, tanto per dirne solo qualcuna, sono superiori ai normali sata.

Inoltre i 15k.6 come prestazioni sono migliori dei 15k.5, non sono proprio equivalenti... il transfer rate teorico max di un 15k.6 è sui 165-170 mb/s.... per i 15k.5 assi minore... il consumo dei 15k.6 è minore dei 15k.5 rispetto al traffico transazionale, che è superiore per i 15k.6...

Basta leggere un poco sul web... e sui datasheet seagate...

La generazione 15K.5 è stata la prima ad infrangere i 120 MBytes/secondo...125 per l'esattezza che non sono pochi.
Inoltre i 15K.5 anche S.A.S si trovano ad un costo inferiore...
I 15K.6 utilizzano il sistema di power trimming per ridurre l'assorbimento di potenza elettrica e la dissipazione termica.

Grazie.

Marco71.

[Marco71]

Originariamente inviato da Pelvix

Ma ATTO non è uno dei più affidabili?
Il file da 2,8 GB è una iso.
Ho installato Diskeeper 2008 Pro Premier

...aderente alla "realtà fisica" è la suite IOMeter personalizzata magari con uno schema di uso.
Prima di tutto il codice di ATTO è abbastanza "piccolo" da poter essere posto in uno dei livelli della memoria cache del processore centrale...almeno nelle routine più critiche.
Non si adatta comunque bene a sistemi con controllori sofisticati come quelli in oggetto.
La storia dei programmi di benchmark dal responso poco aderente al modello della realtà che dovrebbero appunto simulare, è vecchia.
Negli anni '80 in piena epoca di personal computing, tanta gente si faceva affascinare da un certo Landmark speed...scritto per una o due generazioni di processori x86 precedenti alla 80486, mostrava a schermo valori fantascientifici...mai ottenibili nella pratica.
Grazie.

Marco71.

[Marco71]

Originariamente inviato da Pelvix

Io ho sia l' UPS che la batteria tampone del ctr, quindi deduco che sia meglio il settaggio "Write back" per me, giusto?

PS: se cambio il settaggio di "Write" devo reistallare tutto?

...nessun cambiamento alla matrice né sua ricostituzione.
Grazie.

Marco71.

[khael]

Originariamente inviato da Marco71

...nessun cambiamento alla matrice né sua ricostituzione.
Grazie.

Marco71.

ma che cambia fra una e l'altra?
anche io sn dietro ups e con batteria sul ctrl =)

[Marco71]

Originariamente inviato da khael

mi ero perso che i 15k.6 sono arrivati a 260€ e che i 15k.5 sono fermi a oltre 200e mi sembrava costassero meno
sull'mtfb ok
sui tempi d'accesso e transfert rate non sono d'accordo mi spiace

cmq ripeto sarei felice di fare test su singolo hd! e stesse partizioni
scusate i molteplici edit:
io faccio 6ms sull'intero hd con 4hd in raid, lui 3 e qlk cosa con 2hd sulla prima parte dell'hd non mi sembrano valori assolutamente confrontaibli
non credi?

per il resto del discorso non hai mai nemmeno lontanamente pensato che 4hd in raid0 sarebbero andati meglio di 4 volte rispetto a un normale hd nell'aprire word..
mi aspettavo prestazioni migliori tutto qui

...appunto...
Il termine inglese corretto è "transfer rate" non "transfert" che è un termine usato in psicoanalisi.
Grazie.

Marco71.

[Marco71]

Originariamente inviato da khael

ma che cambia fra una e l'altra?
anche io sn dietro ups e con batteria sul ctrl =)

...in write through non esiste nessuna moderazione nelle transazioni di scrittura dirette alle unità facenti parte della matrice.
In write back il controllore ottimizza il flusso di dati in scrittura diretto agli hard disk anche tenendo conto, ad esempio, sulla posizione delle testine degli stessi.
Molti la definiscono anche "lazy writing".
Stesso concetto che si applica anche ai controllori di memoria cache presenti sui processori.
In write through comparirebbe una enorme mole di transazioni di scrittura da e verso la memoria centrale con pesante occupazione di banda passante sia esso un front side bus oppure una connessione punto-punto.
Secondo il protocollo M.E.S.I ad esempio la scrittura in memoria centrale avviene solo quando una locazione di memoria contiene un valore differente da quello contenuto in un dato livello della gerarchia di memoria cache.
Grazie.

Marco71.

[Marco71]

Originariamente inviato da il menne

Beh, qualcosa di più certo lo potrò dire solo dopo che li avrò usati per un poco.... per ora ci ho fatto solo bench.... comunque sembrano molto più reattivi dei normali hd a 7200... e non poco....

...paragonare unità da 7200 giri/minuto con il non plus ultra delle meccaniche per hard disk...S.A.S per di più con trasmissione/ricezione full-duplex, attuatore del gruppo testine molto ma molto più rapido sia nelle accelerazioni che nei movimenti fini...ecc. ecc.
Ma per notare questa differenza basta utilizzare tutti i giorni un modesto sistema S.C.S.I con unità 15K.4 ad esempio.
Grazie.

Marco71.