Problema con LSI MegaRAID 320-2E

[Star trek]

Riporto anche qualche test fatto con Everest.









Poi vedo con Sandra.

[basanet]

Eccomi! Ho fatto anch'io qualche test con Everest (versione 5.01). I risultati, in effetti, non sono sempre distanti, ma restano alcuni abissi. La meccanica conta. Indubbiamente.
Innanzitutto il "read test suite":

[basanet]

Il "linear read":

[basanet]

Il "linear read":

[basanet]

Il "buffered read":

[basanet]

E, infine, l'"average read access":

[Star trek]

Originariamente inviato da basanet

Il "linear read":

Gli affondi che vedi sono probabilmente programmi che accedono al disco quando è sotto test e probabilmente si tratta di file di modeste dimensioni perché con più sono piccoli e con più il disco è lento a leggere...ovviamente.Probabilmente lo stai usando anche tu come disco di sistema. Tuttavia c'è da chiedersi cosa cambia a metterci più cache. Mi pare che siano DDR.Il banco che ho io monta dei chip UCCC. Non so i tuoi.Trovare un banco da 1gb o 2gb di DDR non è difficile costano ormai poco.Tra l'altro quello attuale non mi sembra neanche un ECC. A patto che quantitativi di questo tipo servano a qualcosa e siano riconosciuti dal controller. Fino a 512 dovrebbe farlo perché ci sono come ricambi originali.

[CRL]

Originariamente inviato da Star trek

Gli affondi che vedi sono probabilmente programmi che accedono al disco quando è sotto test e probabilmente si tratta di file di modeste dimensioni perché con più sono piccoli e con più il disco è lento a leggere...ovviamente.Probabilmente lo stai usando anche tu come disco di sistema. Tuttavia c'è da chiedersi cosa cambia a metterci più cache. Mi pare che siano DDR.Il banco che ho io monta dei chip UCCC. Non so i tuoi.Trovare un banco da 1gb o 2gb di DDR non è difficile costano ormai poco.Tra l'altro quello attuale non mi sembra neanche un ECC. A patto che quantitativi di questo tipo servano a qualcosa e siano riconosciuti dal controller. Fino a 512 dovrebbe farlo perché ci sono come ricambi originali.

Quella è una random read, non una lettura sequenziale, quindi i picchi da ognuna delle due parti dipendono da quale settore l'algoritmo di random va a pescare. Guardando quel grafico si vede che è sostanzialmente periodico, quindi l'algoritmo di random genera serie di numeri che dopo un po' si ripetono quasi uguali. Ovviamente anche l'accesso di un programma genererebbe lo stesso effetto visivo, ma il fatto che siano così regolari in tutti i versi mi fa pensare che sia proprio il pattern di prova che sia quello.

Aumentare la cache non ha effetti significativi sulle prestazioni globali. Coi controller Adaptec il software a corredo tiene un log dei cache hit e cache miss, ovvero quante volte il dato richiesto è nella cache e quante deve essere letto dal disco, e nel mio caso, che è poi un utilizzo standard del pc, la prima era una percentuale ridicola della seconda.

- CRL -

[Star trek]

Ha ragione per il random read!. Però il mio non lo fa. Ascolta ma nel menù del LSI ho visto che non si possono modificare le impostazioni in scrittura perchè non ho la BBU. Secondo Disk Mark in scrittura (non distruttiva èerchè ho dei dati sopra) le prestazioni sembrano abbastanza scadenti. Cosa cambia a metterci anche la BBU? Cambia la scrittura con la BBU?



Basanet se hai voglia prova a fare anche tu il test con Disk Mark che mi pare che tu abbia la BBU.

[CRL]

Non sono basse quelle prestazioni, non puoi confrontarle con quelle del read, le prime due sono letture dalla cache, magari facessero 500MB/sec.

Se metti la BBU ti fa abilitare la cache in scrittura, la batteria garantisce che se anche il pc si spegne mentre i dati sono in attesa di essere scritti il controller rimane alimentato per ordinare la scrittura degl stessi sul disco, ma tanto il disco non è alimentato se non hai un UPS, quindi non li scrive uguale, e se avessi un UPS allora non serve la BBU, perchè ci pensa lui.

Se metti la BBU e abiliti la cache in scrittura le velocità di scrittura diventeranno gli stessi 500 e passa MB/sec della lettura, ma sono valori fittizi, privi di significato, per questo quel test non mi piace granchè. Troppo facile sarebbe se un banco di memoria da 500kb e una batteria potessero decuplicare le prestazioni di un disco.

- CRL -

[Star trek]

Originariamente inviato da CRL

Non sono basse quelle prestazioni, non puoi confrontarle con quelle del read, le prime due sono letture dalla cache, magari facessero 500MB/sec.

Se metti la BBU ti fa abilitare la cache in scrittura, la batteria garantisce che se anche il pc si spegne mentre i dati sono in attesa di essere scritti il controller rimane alimentato per ordinare la scrittura degl stessi sul disco, ma tanto il disco non è alimentato se non hai un UPS, quindi non li scrive uguale, e se avessi un UPS allora non serve la BBU, perchè ci pensa lui.

Se metti la BBU e abiliti la cache in scrittura le velocità di scrittura diventeranno gli stessi 500 e passa MB/sec della lettura, ma sono valori fittizi, privi di significato, per questo quel test non mi piace granchè. Troppo facile sarebbe se un banco di memoria da 500kb e una batteria potessero decuplicare le prestazioni di un disco.

- CRL -

No beh chiaro che la BBU non fa miracoli.Più che altro non pretederei avere 500mb/sec in scrittura reali...ma neanche 70/80.Che poi avere 70/80mb di trasferimento su blocchi da 512k non sono pochi. E per quanto riguarda il cache delle DDR incide su un disco di sistema? Vabè che molto dovrebbe andare su RAM centrale.Comq quando avrò mogli vedrò di trovare altri due dischi uguali anche vedere Seven reattivo come il 2000 non è male .

[basanet]

@Star Trek

Eccomi! Di volata, ti posto i risultati del Crystalmark:



C'è qualche dato che risulta sensibilmente miglire del tuo, ma credo perchè il tuo disco è di sistema, il mio no. Infatti - anche in merito alla tua considerazione sui cali nel grafico del ramdon read - ribadisco che il mio disco non è usato come unità di sistema. Ci ho - è vero - installato sopra un SO, ma al momento ho caricato WinXP SP3 da un altro disco, quindi l'array SCSI è del tutto "passivo".

Quanto alla RAM, onestamente non so dirti se un incremento possa tradursi in un miglioramento delle prestazioni. Tempo fa - mi pare - lessi alcune considerazioni in tal senso su qualche forum, e tutti coloro che si erano espressi lo avevano fatto in termini pessimistici, alcuni per altro sulla scorta di esperienze personali. Se - tuttavia - mi dovesse capitare l'occasione di provare un modulo DDR sul controller (dovrei averne ancora un paio, addirittura da 1GB, da qualche parte), ti farò sapere i risultati.

Per tutto il resto, direi che possiamo stare contenti delle prestazioni dei nostri rispettivi sistemi: anni luce di distanza anche dal più performante sistema SATA! Perchè il mercato nell'ambito tecnologico non seleziona sempre gli standard migliori? La natura lo fa...

[basanet]

Buongiorno!

Confesso che ero un po' turbato dal discorso di Star trek relativo all'ampiezza di banda degli slot PCI-Express, così ho condotto una ricerca per venire a capo del'incongruenza tra quanto c'è scritto sul manuale della mia P5K Deluxe (che sostiene che sia lo slot grafico che quello "nero" viaggiano a x16) e le specifiche riportate dal sito della ASUS (che danno il "nero" come funzionante a x4 o a x1).

Alla fine credo sia venuto fuori che avevo capito male io: siccome si parlava di uno slot x1 che veniva disabilitato se l'altro veniva attivato a x4, avevo assunto che i due x16 facessero discorso a parte. Poi ho scoperto che lo slot x4 di cui si parla altro non è che il x16 "nero". L'equivoco nasce dal fatto che gli "slottini" x1 in realtà sono due, così che (mi) sembrava che fossero proprio questi a fare il "giochino" de "se ne usi due, viaggiano a x1, se ne usi uno a x4 l'altro non va". Invece no! La situazione, spiegata molto bene qui, è che lo slot PCIe grafico viaggia sempre a x16, quello "nero", se usato, viaggia a x4 e disabilita i due piccoli, che altrimenti, lasciando inutilizzato il "nero" o usandolo a x2 (è autosensing), vanno appunto a x1.

Scusandomi per la mia digressione in parte OT, giungo quindi alla conclusione finale: il mio Perc 4e/DC al momento sta (verosimilmente) viaggiando su uno slot PCIe a x4, il che è perfettamente conforme con le specifiche richieste per il suo corretto funzionamento. Quindi i miei test non dovrebbero essere inficiati da limitazioni della banda del bus.
Il condizionale, così come il "verosimilmente" tra parentesi poco sopra, sono d'obbligo, poichè essendo lo slot x16 "nero" un autosensing, non ho modo di impostare manualmente la banda a x4 anzichè a x2 (la x1, almeno, non risulta tra le opzioni), quindi non posso escludere del tutto che il mio povero Perc stia in realtà in uno stretto slot PCIe x2... ma dai test non si direbbe!

Buona domenica!

[Star trek]

Riprendo ulteriormente il discorso del test in scrittura fatto con Disk Mark commentato da CRL.Effettivamente DM scazza e non poco.Stamattina ho istallato Virtualbox e ho creato un suo disco virtuale do 20gb sull'array SCSI e ho visto che la barra di creazione andava parecchio svelta rispetto alle altre volte . Allora ho aperto HD Tune e sono andato nelle sezione Disk monitor per vedere quanto IO e tranfert faceva e il risultato è stato questo:



Quindi mi pare ottimamente in linea con le aspettative.

Altra questione.Ho provato a creare una striping di 2k anzichè di 64 e le prestazioni era più che penose.Pertanto sconsiglierei di utilizzare striping così piccoli.Mi resta cmq il dubbio di testare uno striping di 128k cioè il massimo consentito dal menu del controller.Siccome il mio è un array su disco di sistema,lo farò forse alla prossima istallazione.

Ho notato che la configurazione da Web Bios ha problema con la creazione manuale degli array nel senso che sempre e comq se si scieglie un RAID0 ,nel web bios viene selezionato sia un RAID0 che un RAID1. Configurazione non effettuabile con soli due dischi.Ho utilizzato l'altro menù,quello stile dos per intenderci e il problema non vi è. Pertanto ritengo la questione legata al Web Bios.Certo che il supporto del mouse sul menu Dos si poteva anche mettere.

Originariamente inviato da basanet

Buongiorno!

Confesso che ero un po' turbato dal discorso di Star trek relativo all'ampiezza di banda degli slot PCI-Express, così ho condotto una ricerca per venire a capo del'incongruenza tra quanto c'è scritto sul manuale della mia P5K Deluxe (che sostiene che sia lo slot grafico che quello "nero" viaggiano a x16) e le specifiche riportate dal sito della ASUS (che danno il "nero" come funzionante a x4 o a x1).

Alla fine credo sia venuto fuori che avevo capito male io: siccome si parlava di uno slot x1 che veniva disabilitato se l'altro veniva attivato a x4, avevo assunto che i due x16 facessero discorso a parte. Poi ho scoperto che lo slot x4 di cui si parla altro non è che il x16 "nero". L'equivoco nasce dal fatto che gli "slottini" x1 in realtà sono due, così che (mi) sembrava che fossero proprio questi a fare il "giochino" de "se ne usi due, viaggiano a x1, se ne usi uno a x4 l'altro non va". Invece no! La situazione, spiegata molto bene qui, è che lo slot PCIe grafico viaggia sempre a x16, quello "nero", se usato, viaggia a x4 e disabilita i due piccoli, che altrimenti, lasciando inutilizzato il "nero" o usandolo a x2 (è autosensing), vanno appunto a x1.

Scusandomi per la mia digressione in parte OT, giungo quindi alla conclusione finale: il mio Perc 4e/DC al momento sta (verosimilmente) viaggiando su uno slot PCIe a x4, il che è perfettamente conforme con le specifiche richieste per il suo corretto funzionamento. Quindi i miei test non dovrebbero essere inficiati da limitazioni della banda del bus.
Il condizionale, così come il "verosimilmente" tra parentesi poco sopra, sono d'obbligo, poichè essendo lo slot x16 "nero" un autosensing, non ho modo di impostare manualmente la banda a x4 anzichè a x2 (la x1, almeno, non risulta tra le opzioni), quindi non posso escludere del tutto che il mio povero Perc stia in realtà in uno stretto slot PCIe x2... ma dai test non si direbbe!

Buona domenica!

Il controller offre una connessione elettrica a 8x mentre la tua configurazione attuale dello slot nero appare essere limitata a 4x.Diciamo che con 2 dischi non dovresti avere problemi neanche con una connessione elettrica a 2x ma se aumenti i dischi sempre in RAID0 allora l'eventuale 2x diventa piccolo.Si dice che il PCIe 1x abbia una banda passante TEORICA di 250Mb/sec,mentre dalle precedenti limitazioni che avevo io sembra che sia molto meno.Se la banda 1x fosse davvero 250mb non avrei avuto bisogno di switchare la mainboard visto che i miei dischi arrivano a circa 230-240mb in attuale configurazione.Ancora una volta i valori teorici sono ben lontani da quelli pratici.Io direi che quando si hanno 170-180mb di banda per ogni linea PCIe direi che è più attendibile.

Bye

[basanet]

@Star trek
Sì, hai ragione, sono io che ho sbagliato a fare i conti. Nel manuale ufficiale (cfr. pag. 3-13) in effetti viene indicata una banda passante teorica massima di 2 GBytes/s, che - da un rapido calcolo - risulta essere pari appunto a x8 connessioni elettriche... peccato che la mia P5K Deluxe non sia in grado di andare oltre i x4! Resta comunque un bel salto in avanti rispetto a qualsivoglia sistema IDE e - tenuto conto anche delle tue considerazioni sui limiti concreti delle bande passanti teoriche - anche dei sistemi SATA2.

Quali altre schede madri hanno oggi un secondo slot x16 capace di raggiungere almeno gli x8 effettivi, che tu sappia? In giro per i siti ufficiali dei vari produttori è piuttosto difficile fare una ricerca impostando questo "filtro" di selezione...

[Star trek]

Ma difatti è una cosa un pò assurda.Quando avevo il 939 la A8R32 aveva 32linee elettriche disposte su due slot PCIe 16x meccanici. con i socket successivi e l'aumernto delle porte PCIe si è presentata il problema che le le linee alattriche potevano essere meno rispotto alla capienza meccanica. Per esempio al Asus M4A79 Deluxe ha 4 slot PCIe meccanici ma ovviamente non tutti assieme a 16x.Il chipset è un 790FX. Se passi al GX hai già delle limitazioni come la mia MOBO.

Difatti nella M4A79 con il 790FX vi è scritto : "x PCIe 2.0 x16 support ATI CrossFireX™ technology (@ dual x16, triple x16 / x8 / x8, or quad x8 link)"

Mentre nella M4A78 con il 790GX vi è scritto: "x PCIe 2.0 x16 (Single x16 with VGA Switch Card or Dual x8)*. Support ATI CrossFireX™ technology"

Dovrebbero essere tutte connessioni PCIe 2.0 quindi considera che sono più efficienti delle precedenti.Se hai scheda video e mobo in quel modo ( come me) il problema non dovresti vederlo.Difatti io se ti ricordo ho fatto un test con 3Dmark advantage e non ho avuto una manciata di punti di differenza assolutamente trascurabili e credo che l'Advantage sia abbastanza attendibile per mettere sotto stress la macchina. Tuttavia la sorte vuole che il mio kuma non si riesca a sbloccare con l'ACC o perlomeno in AUTO se lo metto in manuale e abbasso la percentuale la macchina non parte e questo credo che significhi che i core bloccati non funzionino per niente. MA cmq secondo me non di devi preoccupare perche da quello che ho letto in giro il limite dei MAU nel transfer rate è quello che raggiunto tu.Quindi stanno dando tutto quello che possono. . I 15K.5 hanno la stessa meccanica dei SAS con dischi da 2.5 qundi molto veloci solo che abbinandoci una interfaccia seriale vanno ancora meglio ma non troppo. Peccato che i SAS non si possano utilizzare su controller SATA Onboard anche se il contrario si fa. Cmq su http://www.hwupgrade.it/forum/showthread.php?t=1805409 c'è una discussione aperta sul PERC 5 per i SAS. Magari ci do un occhio per i confronti e trovo qualcuno che ha un RAID0 con due 15K.5. Nella prima pagina scrivono che quel controller ha problemi con le schede madri INTEL.

[basanet]

@Star trek
Le tue argomentazioni mi incoraggiano ad affrontare qui alcuni miei "dubbi amletici" che, pur applicandosi in qualche modo a tutto il mondo dei dischi, assumono tuttavia una valenza particolare nell'ambito della tecnologia SCSI, in quanto mirano ad analizzarne l'autentico merito prestazionale (tralasciando quello nell'ambito dell'affidabilità, che certamente è già un punto a favore dello SCSI).

Vorrei capire quanto e come questo nostro amato standard abbia il merito di fornire le tanto decantate prestazioni superiori. In relazione a ciò, mi sono posto delle domande cui probabilmente molti articoli (e ancor più numerose pubblicità) hanno già provato a rispondere all'epoca del lancio delle singole tecnologie di cui stiamo parlando. Per tacere di tutti gli articoli tecnici analitici che sono seguiti negli anni. Ma - forse perchè sono di coccio o forse perchè le fonti che ho trovato non sono state quelle giuste - continuo a pormi quelle stesse domande.

In particolare mi chiedo se, partendo dal presupposto che la banda di 3GB/s del SATA, se reale, non dovrebbe rappresentare in sé un collo di bottiglia, il motivo del fatto che le prestazioni di un disco SATA sono decisamente inferiori ad uno SCSI possa essere individuato in uno di questi:

1. throughput oggettivamente molto basso degli HDD SATA, indipendentemente dal controller
2. gestione inefficace della banda teorica di 3GB/s, con conseguenti ed effettive limitazioni per le singole unità collegate al controller
3. ampiezza di banda semplicemente molto gonfiata e quindi lontana dai 3 GB/s dichiarati.

Per quanto riguarda l'analisi del throughput, direi che un test interessante potrebbe essere quello con dischi SAS e SATA2 su un controller SAS: avremmo il medesimo campo di analisi, cambiando solo quello che ci interessa, ovvero l'architettura del disco. Io però non ho l'hardware per questa prova... bisognerebbe chiedere - proprio come hai suggerito tu - ai (felici?) possessori di un Perc 5.

Circa la gestione della banda come parametro più significativo di quanto non sia l'ampiezza della stessa, ho invece un'esperienza personale che mi ha dato da pensare. Tempo fa smanettavo con il mio vecchio Adaptec 39320A-R, dotato di attacco PCI-X, ma installato su un normalissimo PCI 2.0, la cui ampiezza di banda è 133 MB/s (32 bit x 33 MHz / 8). Be', non ci crederai, ma ottenevo già risultati notevolmente migliori rispetto a qualsivoglia altro disco SATA collegato allo stesso sistema! Se riesco a trovare - ammesso che li abbia salvati - i log dei test che avevo fatto, li posto volentieri.

La controprova del fatto che la banda teorica abbia un peso molto relativo sulle prestazioni del sistema l'ho avuta successivamente, testando il medesimo comparto dischi (Adaptec 39320A-R con gli stessi HDD SCSI del primo esperimento) su una Asus NCCH-DL, sulla quale il controller era alloggiato in un più consono slot PCI-X, di ampiezza di banda quadrupla rispetto ad un normale PCI 2.0, potendo raggiungere teoricamente i 528 MB/s (64 bit x 66 MHz /8). Le prestazioni sono indubbiamente migliorate, ma non di così tanto quanto ci si poteva aspettare.

Riassumendo, la configurazione in RAID 0 di due (vecchi) Fujitsu MAT (da 36GB l'uno) ha dato molto più di quanto ci si aspettasse con il controller su PCI 2.0, pur con i limiti (non troppo teorici) della banda a 133 MB/s, mentre quando i due dischi avrebbero potuto "scorrazzare" liberamente nella vastità della banda PCI-X, i risultati sono migliorati solo di un po'...

Questo basta a considerare più cruciale la gestione della banda rispetto all'effettiva ampiezza della stessa? Be', se così non fosse, secondo me sarebbe comunque una buona "prova indiziaria", oltre che un interessante punto di partenza per studiare l'effettiva apertura del canale del controller SATA da 3 GB/s nominali...

Il test va ancora pensato... e il post è diventato già incredibilmente lungo! Ma magari, prossimamente...

[Star trek]

Il limite a mio avviso è solo uno.Anche con un disco di 1,8 pollici con l'aumento delle velocità di rotazione,la meccanica arriva a un limite difficile da passare a causa del limite magnetomeccanico delle testine.Se tali meccaniche riescono a lavorare con motori a rotazione lenta dell'ordine dei 4200-5400-7200,iniziano ad avere problemi con motori più veloci. Mi pare che dischi da 1,8 veloci non ne siano ancora stati fatti.Questo un perché le meccaniche sono ormai limitate confronti al futuro visto negli SSD.Pensa ai dischi SAS che seppur potenzialmente più veloci degli SCSI hanno soltanto un grosso divario nel prezzo. Oggi si possono trovare dischi U320 piuttosto veloci a prezzi davvero contenuti.Se poi hai la fortuna di avere una scheda madre con uno slot PCI-X tipo le Asus WS allora risparmi anche sul controller .Non è raro trovare controller con la C maiuscola (non HBA quindi) a prezzo più che accessibili su PCI-X.Il discorso cambia se vai di connessione PCIe che essendo più recente ( ma non necessariamente più veloce) la sua versatilità incide sul costo. Personalmente se avessi avuto una mainboard con slot PCI-X ,non avrei esitato a cercare un controller da metterci anche fronte di un eventuale PCIe libero.Questo perché il controller PCI-X non hanno bisogni di bridge per interfacciarsi al contrario dei controller PCIe.Difatti avevo pensato di prendere una scheda madre con il PCI-X solo che su AM2+ c'è veramente poco oltre ad ASUS che non amo particolarmente per via di precedenti problemi con schede madri e relativa assistenza. Sì il SATA2 han una banda teorica invidiabile...come del resto il Sata 3 (mi pare 600) ma sono tutti dati di targa che contano ben poco nell'uso pratico. Il problema rimane sempre la meccanica.Cosa risolta parzialmente con u nuovi dischi 7200.12 nei quali sono riusciti ad aumentare il tranfer rate ma di miglioramenti sull'access time non se ne parla con le attuali meccaniche e piatti da 3,5" pollici. Ma che ci mettano dei dischi più piccoli o dopo diventano dei SAS ? . Gli SSD attuali anche se hanno un tranfer rate lento hanno un invidiabile access time e questo li rende interessanti sull'accesso a file di dimensioni miste.

Concludendo non sono molto attirato da un eventuale configurazione sas .Questo un pò per il prezzo ma anche perché con un paio di SSD discreti si può arrivare a prestazioni migliori con meno cavi a spasso per il case,minor consumo,minor calore. Come utente Home se cambierò config sarà perché passo a SSD e non a SAS il quale gode di un mercato PRO ancora più di nicchia che lo SCSI.

[Star trek]

L'altro giorno ho avuto la possibilità di provare questo controller su una macchina con Windows server 2008 R2 convinti che avesse i driver dentro...e invece non sembrano esservi.Forse è presto? . Maragi con Seven i produttori si mettono in pari.E' un controller strausato quindi o su Seven o sul 2008 qualcosa lo devono mettere.

[basanet]

Ciao! Be', non saprei. In ogni caso mi trovi d'accordo: in considerazione della larga diffusione di questo controller (unitamente alla scaristà di alternative!), è molto probabile che il driver venga presto inserito nel database di Win2008 Server... Non resta che asppettare e sperare. In ogni caso terrei d'occhio il sito della LSI.
Ciao!