Scsi troppo lento: che fare?

[Necro_sf3]

Salve,
Ho questo problema: 4 dischi scsi3 da 18GB configurati in raid 0 mi danno solo un transfer rate di 20 MB/s. (os: win xp)

Il controller è un IBM serveRAID4l collegato su uno slot pci di una mainboard asus con chipset nforce3 250, i dischi sono 4 HP da 18,2GB ciascuno, 10000 rpm scsi3.
Il cavo di collegamento è un 320 con terminatore attivo.
Ora, il controller (bios,firmware e drivers compatibili, tutti v. 7.10.18) riconosce i dischi, me li fa configurare, poi creo la partizione, formatto (ho provato sia il raid 5 che il raid 0 con 2 dischi per volta per vedere la differenza... il raid 5 va a 15 MB/s)
Il tutto lo confronto con un sata da 160 GB presente nello stesso sistema (disco c, che va a circa 50/55 MB/s

Ho visto che il tempo di accesso dello scsi è molto inferiore al sata (6 contro 10ms) ma è possibile che il tranfer rate sia così basso??
Ho provato diversi benchmark e tutti danno più o meno gli stessi valori.

So che usando uno slot PCI normale non posso sperare in valori altissimi, ma 20 non sembra troppo poco?

In attesa di suggerimenti, ringrazio per l'attenzione

Alessandro

[CRL]

Sì, è troppo basso...
Innanzitutto dovresti controllare di aver collegato tutto bene, il ctrl scsi andrebbe sulla prima pci partendo dall'AGP, e dovrebbe avere IRQ7, e questo lo vedi anche dall'utility del Bios (io avevo un Serveraid 3L, quindi so come è fatta). I dischi vanno settati coi jumper con gli ID 0-1-2-3 e collegati in ordine inverso, cioè lo 0 deve essere quello sull'attacco subito prima del terminatore, e gli altri a seguire verso il ctrl.
Poi mi dici con precisione il modello dei dischi, anche se 30MB/sec minimo ognuno lo fanno di sicuro...
Poi, sempre dal Bios del ctrl, devi verificare che il tutto venga rilevato correttamente, direi di collegare prima un disco da solo, e vedere che transfer fa questo, e poi eventualmente costruire l'array.
Se non sbaglio, il ctrl ha l'opzione del Bios "Write Configuration to Disk", e ricordati di farla quando costituisci l'array.
Controlla dal Bios se tutto risulta scsi-3, dovrebbe darti indicazioni in merito.
Lo stripe size del Raid a quanto l'hai messo?
Il valore dovrebbe essere tra 16 e 128, tipicamente, in genere 32 o 64 per il s.o., mentre se si usa l'array per dei dati si aumenta un po'.
Verifica un po' tutte 'ste cose, e fai il test del transfer con HDTach, e magari se riesci posta lo scrennshoot con il diagramma che ne viene fuori...

- CRL -

[sgrisol@verklok]

grazie crt per le splendide indicazioni..interessa anche a me

[Necro_sf3]

Grazie mille!!
Più tardi farò le prove che mi hai consigliato.
Solo un paio di punti.
Nel frattempo ho verificato che in termini di prestazioni, tramite diverse prove, facendo l'array con un solo disco si comporta come se ci fosse un raid0 con tutti e quattro (test con ATTO)

Inoltre per via delle dimensioni del controller lo posso tenere solo nell'ultimo o nel penultimo slot PCI. Nell'ultimo ha L'irq condiviso con la iee1394, che però disabilito.

Lo stripe size del raid credo che sia di default a 8... e non so come modificarlo.

Write configuration to disk quando esattamente lo devo fare? prima di partizionare l'array? dopo?
Metterò gli id correttamente (ora mi sa che sono in ordine sparso) anche se non pensavo che ciò potesse interferire con le prestazioni.

Ti ringrazio ancora per il tempo e la disponibilità.
Appena fatto i test, ti faccio sapere.

Alessandro

[CRL]

@ sgrisol@verklok: ...io sono CRL, non CRT, ma perchè sbagliate tutti???

@ Necro_sf3: il test con ATTO non ho capito cosa voglia dire, io di atto conosco solo i ctrl. Tipicamente si parla di array solo se c'è il raid, questa una precisazione inutile.
Lo stripe size si setta quando fai l'array, quindi il raid, e non si può modificare fino a quando non lo rifai. WCtD lo dovresti fare dopo aver creato l'array, cioè prima di riavviare, è una sorta di salvataggio ulteriore della configurazione anche sui dischi, oltre che sul ctrl.
Il discorso IRQ e ID quando va tutto bene non cambia nulla, ma in caso di problemi sarebbe opportuno fare le cose secondo la regola, per evitare di aggiungere possibili incongruenze...
Su che IRQ stà il ctrl?

- CRL -

[Necro_sf3]

Ciao CRL e grazie ancora...

Dunque,
Il ctrl usa l'IRQ 17, condiviso con un IEE1394, che è comunque disabilitato, e che non uso.
ATTO è il nome di un benchmark per hd, che distingue velocità di lettura e scrittura... l'ho provato perchè lo avevo visto su un altro forum... americano, credo. Con questo benchmark vedo che i dischi in raid0 arrivano ad un valore massimo di lettura di quasi 90 MB/s, mentre la scrittura si ferma a circa 40 (valore massimo che, se è il burst, corrisponde al valore del test HDtach)

Curiosità: il sata maxtor da 160 giga si comporta in modo inverso: la scrittura arriva a 70-80 (max), e la lettura si ferma a 40 circa (max)

Sono riuscito a modificare lo stripe size! Passando da 8 a 64 si è effettivamente vista una differenza: il raid0 da 4 dischi passa da circa 20 a circa 25 con il test HDTach che mi hai suggerito.
Ho effettuato anche la prova con un disco solo, che dà un risultato di circa 20.
In questi 2 giorni non ho avuto molto tempo per fare test, o per smontare i dischi, ma ricordo che sono uguali a coppie: due sono seagate ceetah e due credo maxtor, ma ora non ricordo il modello. Precisazione: i due ceetah sono SCA cui ho messo i riduttori da 80 a 68 pin. Pensando che anche questa potesse essere fonte di noie, ho provato a testare i dischi a coppie, ma non ho osservato differenze tra la coppia di 80 pin e quella nativa a 68.

Riassumendo, ho fatto un piccolo passo avanti con lo stripe size, ma il raid0 (4 dischi) va più o meno ancora come un disco singolo o poco più.

Appena ho un pò di tempo procedo con altri test, nel frattempo, cosa ne pensi?
Hai altri suggerimenti?
Grazie,

Alessandro

[CRL]

...mmmhhhhh...
...ti rispondo al volo, perchè anche io ho poco tempi in questi giorni, alcune cose sono un po' strane, in particolare le testine di lettura e scrittura sono sullo stesso braccio, e nelle operazioni sequenziali, una volta posizionate, leggono o scrivono tutto ciò che capita sotto, cioè tutti i dati che passano, che dipende dalla densità e dagli RPM. Per questo motivo le velocità di lettura e scrittura sequenziale sono uguali.
Sono esclusi da questo solo il raid5, in cui nella scrittura il ctrl deve calcolare e scrivere la parità, e risulta più lento, ma per il raid 0 dovrebbero essere uguali.
Proverò a vedere il programma atto

- CRL -

Edit: mi dici come l'hai configurato il test? Il programma sembra buono, e testa sia lettura sequenziale che casuale, con varie profondità della coda.
Mi rimane la domanda su come faccia il test in scrittura, dato che sul disco c'è della roba, a me la velocità di lettura e scrittura è sostanzialmente allineata, diciamo che le differenze sono piccole.
Mi rimangono ancora da capire un po' di cose, ad esempio in un test è arrivato a darmi più di 1GB/sec di transfer...

[Necro_sf3]

Ciao CRL,

Ho fatto qualche prova in più.
Gli altri due dischi sono fujitsu marcati HP, seriale nr.MAJ3182MP, ultra3.

Ho provato a testare ciascun disco da solo, con lo stripe size a 64 (massimo permesso dal ctrl) e stando a quanto dice hdTach il burst non supera 40MB/s, mentre la media sta intorno a 25/30. Ora, siccome è lo stesso comportamento degli stessi dischi messi in raid0 (quindi poco o nessun miglioramento della performance) e siccome 40 è il valore massimo dsella trasmissione a 8 bit (ho letto qualcosa in proposito facendo un poco di ricerca) non vorrei che per qualche oscura ragione il bus si bloccasse a 8 invece che a 16 bit. E' possibile? Il cavo, ho ricontrollato, è testato per i 320 Mb/s, quindi non può essere. Anche il ctrl viene normalmente riconosciuto dal RaidManager come a 160Mb/s, mentre i dischi sono ok. Come è possibile? dove sbaglio? Perchè il raid0 si comporta come se ci fosse un solo disco?

Il test ATTO è l'unico che mi mette qualche dubbio: configurando diversamente ottengo risultati opposti: se il valore Total Lenght è piccolo il disco legge velocissimo (fino a 100 MB/s) e scrive da cani, mentre alzando il valore si ha progressivamente l'inversione della tendenza. MAH!
Non so più quali prove fare per ottenere spunti.

Attendo fiducioso un tuo consiglio....
Ancora grazie per la pazienza ed il tempo.

Alessandro

[CRL]

Sai cosa può essere? ...spesso è trascurata come cosa, ma anche gli adattatori 80-->68 hanno una velocità. Prova a fare un raid0 tra i due dischi a 68 pin, e vedi cosa succede...
Dopo martedì avrò molto più tempo, mi rileggo tutto e ci penso meglio...
Per quanto riguarda il test atto, hai l'help? a me manca il file...

- CRL -

[Marco71]

L'adattatore 68<->80 pin di solito di tipo "passivo" e cioè senza alcun tipo di amplificazione od adattamento di impedenza di tipo "attivo" deve proprio essere mal progettato per introdurre ritardi alla massima velocità di 320MBytes/sec...ma molto male...
Ci possono essere delle capacità parassite ed induttanze parassite distribuite che limitano la velocità dei transienti ma è di solito un fenomeno di ridotto impatto.
Per curiosità mi potresti dare gli "estremi" del cavo S.C.S.I che utilizzi ?
Ha terminatore attivo o passivo ?
Che lunghezza ha ?
Chi è il costruttore del "nastro" se di tipo flat oppure del cavo rounded ?
Grazie.

Marco71.

[Necro_sf3]

Ciao Marco 71,

per rispondreti, spero sia sufficiente riportarti l'intera scritta stampigliata sul cavo....

"Amphenol Spectra Strip AWM 80C LL31941 CSA AWM I A80C 150V FT-1 30AWG Solid ULTRA320 SCSI compliant 17103"

Il terminatore è attivo, tra una "presa" e l'altra per i dischi ci sono circa 30 cm. Il cavo è per 4 dischi + controller.

Direi che il cavo è di tipo flat, color bianco e salmone.

Devo ancora riprovare a testare solo i dischi nativi a 68 pin, ma ricordo che già da un primo tentativo non ci sono grosse differenze rispetto all'array in raid0 da 4 dischi.
Firmware, drivers e bios sono alla stressa versione, 7.10.18, l'ultima.

Ciao

Alessandro

[CRL]

Il fatto che sia un Amphenol esclude che possa essere lui il problema, ma aspettiamo il parere ufficiale...

- CRL -

[Marco71]

...escluderei come causa di problemi di trasferimento il cavo flat S.C.S.I Ultra320 Amphenol....
La sua "consociata" SpectraStrip produce i migliori cavi per l'elettronica al mondo....Amphenol è una garanzia...dovresti solo avere avuto la sfortuna che sia stato assemblato male il cavo nel senso che Amphenol (SpectraStrip) produce solo il nastro senza connettori e terminatore mentre è poi responsabilità di terzi la crimpatura e la dotazione di connettori...l'unico passaggio a "rischio" potrebbe essere solo questa fase di "assemblaggio" del cavo "finito"...
Poi ricorda che ogni scheda S.C.S.I U160 ed U320 esegue la validazione del dominio di trasmissione/ricezione prima di ogni inizio transazione sul bus ergo nel caso di problemi alla max. velocità al massimo si assisterebbe ad un downgrade come fa ad esempio Windows XP in presenza di un numero troppo alto di errori nel resto delle divisioni C.R.C.
Grazie.

Marco71.

[Necro_sf3]

Grazie Marco71,

Ho fatto un altra prova con un solo disco nativo a 68 pin, collegato da solo al cavo e al controller. Stessa cosa.
Prestazioni identiche agli altri dischi presi da soli e al raid0 dei 4 dischi.
Burst sempre di 40MB/s e media tra 25 e 30.

Direi quindi di poter escludere un effetto dei convertitori 80-68 pin.

Mi sembra di capire che 40MB/s sia la massima velocità raggiungibile dal mio sistema, come se il bus fosse a 8 bit invece che a 16. Mi resta da provare solo il cambio dello slot pci del ctrl, poi non ho altri spunti.

E' possibile verificare la performance del controller sul bus pci? anche senza dischi?

Oppure potrei provare a fare un test in ambiente Linux, magari è WIN XP che effettua il downgrade di cui parla Marco71... è possibile?
Conoscete qualche programma utile? Vi sembra una buona idea?
Resto in attesa...
Ancora grazie a tutti

Alessandro

[Marco71]

Per tuo riferimento il mio Hitachi 10K300-73 Ultra320 su Adaptec 29160N si attesta intorno ai 114 MB/sec. con l'uso di HDTach 3.0.1 velocità di trasferimento burst quindi come puoi notare con un buono sfruttamento dei teorici 132MBytes/sec di ampiezza di banda per ogni Master del bus p.c.i canonico con parametri 32bit-33MHz (il valore di 33MHz è troncato nel senso che sono almeno 33.33333...MHz dipende dal valore dell'oscillatore al quarzo).
Acertati anche di:

1) avere installate le A.P.I Adaptec 4.71 prelevabili da www.adaptec.com
2) dimmi su che valore hai impostato il valore del timer di latenza del bus p.c.i...io non andrei oltre il vslore di 64 cicli di clock p.c.i.

3) serve una descrizione del tuo sistema: motherboard ecc.

La migliore gestione del bus p.c.i che io conosca è implementata dalla Intel...gli altri costruttori come ad esempio V.I.A hanno sempre avuto dei problemi...
Grazie.

Marco71.

[CRL]

Originariamente inviato da Marco71

La migliore gestione del bus p.c.i che io conosca è implementata dalla Intel...gli altri costruttori come ad esempio V.I.A hanno sempre avuto dei problemi...
Grazie.

Marco71.

...di questo ero convinto anche io, fino a quando la mia Intel ha avuto gli stessi problemi delle VIA, solo che quelle hanno la patch, come dicevamo nel famosissimo thread...

- CRL -

[Marco71]

...i chipset Intel hanno da almeno 5 anni a questa parte la migliore implementazione "di massa" delle specifiche P.C.I....
Niente a che vedere con la patch per la latenza del timer p.c.i necessaria per regolarizzare l'impiego del bus con i chipset dal Via Apollo 133 in giù....
Ripeto a scanso di equivoci: la patch suddetta è solo per i chipset V.I.A....
Intel ha ottime implementazioni da almeno la serie 820 per non parlare dei vari Natoma 440 ecc., ecc.
I chipset V.I.A sono al confronto dei "giocattoli" con scarsa documentazione...
Intel invece è sovrabbondante di documenti tecnici per i propri prodotti e nel settore c.p.u molto superiore come qualità e quanità di documentazione sia cartacea che elettronica anche ad A.M.D.
CRL i problemi di cui all'oggetto del famoso thread da te iniziato, sono quasi sicuramente da imputare alla coppia scheda 2100S e specifiche restrittive del bus p.c.i in presenza di carichi "elevati" come la gestione di array di due o più h.d in configurazione R.A.I.D-0.
Grazie.

Marco71.

[Necro_sf3]

Dunque... aggiornamento dal fronte:

Ho installato i drivers consigliati da Marco71 della adaptec... nessun risultato.

Il mio sistema è così composto:
MB: Asus KN8e-deluxe, chipset nforce3 - 250
Proc: AMD Athlon 64 3100
Audio: SB Audigy2 zs su slot 3 pci (l'unica pci card insieme al ctrl scsi)
Video: Radeon 9800Pro 256
Ram: 1 gb su un solo wafer (non ricordo la marca, ma nella media. non kingston o simili)
CTRL scsi: IBM serveraid 4L. con cavo Amphenol
HDD SATA: Maxtor da 160GB
HDD SCSI: 2X seagate ceetah 18.2 (marcati HP) + 2X Fujitsu 18.2 (marcati HP) tutti ultra3 da 160MB/s
SO: win xp professional

Il PCI latency adesso è a 128, ma ho fatto anche prove con 64 e non ho riscontrato differenze apprezzabili.

Grazie ancora

Alessandro

[Necro_sf3]

Dimenticavo...

Sono installati i drivers nforce, quindi i driver ide, e quelli del chipset non sono i nativi di windows.

Ci sono suggerimenti?
Test che ancora posso fare?
Il problema è che non dispongo di un altro controller per fare prove...

Grazie,

Alessandro

[Gibson]

Il transfer dell'array lo puoi vedere con winbench99.
Prima è meglio testare un hd da solo, metti un maj3182mp in jbod
e con winbench dovresti ottenere un grafico uguale a questo:
http://www9.plala.or.jp/j-fuji/scsih...0rpm_1/maj.htm
Poi fai lo stesso test con 2 maj3182mp in raid 0, stripe 64k, cache write-back,
usando una partizione unica da 36GB,
se non ci sono problemi dovresti ottenere una linea piatta a 48MB/s
che è la velocità massima che il serveraid 4l riesce a raggiungere.
http://homepage3.nifty.com/sekin/win...transfer_0.png