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??? :muro: :p :p

@ 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]

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... :cry:

- 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/scsihdd/10000rpm_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/winbench/transfer_0.png

[Necro_sf3]

Ciao Gibson e grazie per l'intervento

Ho scaricato winbench, farò i test che mi hai indicato... nel frattempo chiedo: mi stai dicendo che il mio controller può andare al massimo a 48 mb/s?

Se è così perchè lo vendono (e il pc lo riconosce) come 160 mb/s?
Stesso discorso per i dischi ultra3, etcetcetc...
Dov'è la fregatura?

Alessandro

[CRL]

Necro riesci a postare un diagramma di WinBwnch, o di HDTach?
Si capiscono molte cose dal grafico del transfer, c'è da vedere se è piatto, se è altalenante con dominante piatta, o se ci sono picchi che falsano i valori...

- CRL -

[Gibson]

Necro ti ho suggerito winbench perchè in rete ci sono i risultati dei dischi singoli e del serveraid 4l,
così puoi fare una comparazione e guardando la linea del grafico valutare la situazione.
48MB/s sono i risultati che ho trovato in rete.
160 MB/s sono la banda del bus esterno del controller.
Quanto effettivamente venga fatto viaggare sul bus esterno
dipende da altri fattori interni del controller, ad esempio cpu e cache.
Con un i80960RN @ 100 Mhz e 16MB di cache non ti aspettare grandi numeri nel transfer.
Quando man mano aggiungendo dischi in raid 0 la linea del TR diventa piatta
hai trovato il valore del collo di bottiglia.

[Necro_sf3]

Domanda per CRL

Come faccio materialmente a postsare il risultato dei test?

Non sono molto pratico...
Se dovessi descrivere quello di HDtach è una linea perfettamente orizzontale intorno ai 30 MB/s con alcune punte grosso modo equidistanti che arrivano a circa 35.

E' identico sia per un disco, che per un raid0 di due o quattro dischi.

Ciao!!

Alessandro

[CRL]

Per come postare le immagini sul forum c'è una guida di FreeBan:

http://www.hwupgrade.it/forum/showthread.php?s=&postid=4803922

oppure per semplicità guardati qualche discussione con immagini e poi copia-incolla.
Partiamo da un disco solo: se il transfer è piatto, cioè perfettamente orizzontale (a volte con un tratto decrescente all'estrema destra) siamo di fronte ad una limitazione intrinseca della banda (trascuriamo i picchi), dovuta o al controller stesso, o al cavo, o al terminatore, o a qualche settaggio. Questo perchè il transfer di un disco tende ad essere una specie di parabola discendente, e se è piatto vuol dire che c'è qualcosa che fa da tappo.
Ti direi di smontare il ctrl, e di resettarlo, ci dovrebbe essere un jumperino da spostare con scritto reset. Qui:

http://www-1.ibm.com/support/docview.wss?rs=0&q1=serveraid-4l&uid=psg1MIGR-4MMPZ8&loc=en_US&cs=utf-8&cc=us&lang=en

puoi scaricare il manuale del tuo controller, e verificare che tutto sia stato fatto secondo le procedure, e prova a carcare anche come si resettano le impostazioni, anche se io al volo non l'ho trovato (dovrebbe esserci il jumper, comunque).
Direi poi di riprovare, sempre riferendosi ad un disco solo, a fare il test di HDTach. Se non va, allora proverei a mettere versioni diverse di Bios e Firmware, anche se più vecchiotte.

Tutto questo (reset escluso, che farei comunque) a patto che tu sia sicuro del cavo e della terminazione, e forse proverei un altro cavo, anche solo in prestito, per scaramanzia. Poi proverei a forzare il ctrl da Bios sull'IRQ7, se non sai come farlo dimmi che mobo hai, il modello preciso...

Partiamo da un disco solo, fino a quando il diagramma del transfer non diventa la parabola che dovrebbe, solo a quel punto abbiamo sbloccato tutto, ed a mio parere risolviamo anche col raid.

- CRL -

[Necro_sf3]

Ciao CRL..

Oggi mi prestano un altro cavo, faccio una prova e ti faccio sapere.
Allego il grafico di hdtach Quick bench, di cui ti avevo parlato.

Ho visto dov'è il reset jumper... dopo la prova con il cavo, provo anche quello.

Per l'irq la mb è una asus k8n3-deluxe.

Grazie,

Alessandro

[CRL]

E' decisamente piatto come pensavo.
Ho guardato il tuo manuale della mobo (Asus K8NE-Deluxe, giusto?) e a pagina 4.25 c'è la gestione del PCI, che nel bios sta in Advanced-->PCI PnP.
A quanto vedo i vari IRQ possono essere messi o su PCI Device [per assegnarli alle schede PCI], oppure su Reserved [per le schede in modalità ISA Legacy], a noi interessa la prima, ma non è possibile assegnare l'IRQ ad un determinato slot.
Non riesci a cambiare slot alla scheda, per vedere a quale assegna il 7?
Ricorda che l'IRQ devi vederlo dal Bios del Serveraid, e non da Windows, perchè dopo con una funzione apposita gli IRQ sono moltiplicati e riassegnati secondo un'altra numerazione, l'importante è che sia 7 al Bios.

- CRL -

[Necro_sf3]

Allora...

Ho controllato le informazioni del bios. Avevo già provato a settarlo, ma non me lo consente. Da bios vedo tutti gli IRQ disponibili per PCI (come hai detto tu) ma non posso assegnarli io.

Da un controllo sul bios del ctrl, quando fa il boot, vedo: interrupt = 04h.
Ora su windows è al 16, non condiviso con altre periferiche (ne ho rimossa una che condivideva).

Ora sono sullo slot4, ma non posso scegliere che questo o il 5 per motivi di spazio... e le cose non cambiano.

Stasera passo a prendere un altro cavo... francamente è il tentativo su cui ora ripongo più speranze!!! Ti faccio sapere non appena posso.

Ciao!!!

[Necro_sf3]

Effettuato test con altro cavo...

Negativo :mad: :mad:

Funziona allo stesso modo sia un disco che 2 in raid0 con linea piatta a 30 MB/s.


Proverò a resettare il ctrl... ma non credo che possa fare granchè.

Attendo istruzioni. :help: :help: :help:
Grazie,

Alessandro

[demy1981]

Effettuato test con altro cavo...

Negativo :mad: :mad:

Funziona allo stesso modo sia un disco che 2 in raid0 con linea piatta a 30 MB/s.


Proverò a resettare il ctrl... ma non credo che possa fare granchè.

Attendo istruzioni. :help: :help: :help:
Grazie,

Alessandro

ciao, ti scrivo solo per dirti che anche io ho i tuoi stessi problemi con lo stesso controller. Praticamente io uso , o almeno cerco di usare in raid 0 son 2 dischi da 18 gb della maxtor 10K e non vanno più di 35 MB/s, però ho notato che aumentando lo stripe size del file sistem dei dischi, ovvero, portandolo da 64 a 128 fino ad arrivare a 4 MB,(c'è da dire che questo l'ho potuto fare con un programmino che emula solamente questo stripe size a questi valori, visto che il massimo con partition magic è di 64 k), e sono riuscito ad arrivare a ben 60 MB per il test del transfer rate reale del disco e invece a 100MB al secondo con test solo sul bus del controller, tutto questo a 4 Mb come stripe size emulato!!!

Quindi non credo che il controller sia così limitato come banda, e devi considerare che l'ho montato su scheda madre p4p800 che ha slot pci da 32 bit, ed invece il controller lo si può montareanche su pci a 64 bit.

Sinceramente io uso un cavo credo compatibile fino a u2w 80 Mb/s, ma credo che il problema non sia quello visto che un singolo disco su l'altro controller adaptec 2940 U2W (80 MB/s), riesce ad arrivare a ben 55 MB/s. La cosa è molto strana, e ancora non sono riuscito a risolverla.

Fammi sapere se hai notizie a riguardo. Grazie

[AstonSony]

Porto la mia esperienza.
Ho un 2100s con 2 10k7 da 36 Gb 10000 rpm in raid 0.
Con HD Tach 8MB faccio in media 55 Mb/s ed in burst 79 Mb/s.

[cyberjunkie]

Ho trovato questo thread facendo una ricerca con Google, ed anche se è molto vecchio (risale al 2005), ho deciso di postare la mia esperienza, nella speranza che qualcuno che ha problemi con la banda del bus scsi possa ricavarne qualche spunto di riflessione.
Anche se scrivo dal "futuro":D , almeno rispetto alla data di questo thread, la convenienza di utilizzare periferiche scsi, da qualcuno sbrigativamente considerate come defunte (almeno nella loro incarnazione parallela; il SAS, ovvero lo scsi seriale, va alla grande in ambito server, anche per la compatibilità con il SATA), a mio avviso c'è ancora. Anzi, ora più di prima!
Mi spiego meglio: per la tipologia degli utenti di questo forum, o almeno per la maggioranza di essi, l'acquisto di periferiche di memorizzazione ad alte prestazioni è economicamente "fuori portata". Un controller SAS di buon livello su PCI-E, con cache e batteria di backup, più qualche disco SAS da 15K o almeno 10K per farci un array (raid 0 se si ha una struttura di backup funzionale o almeno raid 5 se il backup regolare non esiste o quasi), comporta una spesa totale che è affrontabile da pochissimi.
Anche a livello aziendale (faccio il sistemista, ma volo basso ed assisto realtà piccole, la grande maggioranza non ha nemmeno un armadio rack, per intenderci) queste soluzioni non sono così diffuse, anche perchè ormai le soluzioni SATA hanno raggiunto capacità e anche prestazioni davvero notevoli.
Ma se l gamer o l'utente evoluto si vuol fare un disco di boot che faccia partire il SO (o i giochi) a bomba? Su Ebay, o comunque sul mercato dell'usato/stock ci sono ottime occasioni, proprio in ambito scsi.
Io ad esempio ho preso un IBM 4Lx, molto simile a quello del post originale di questo thread, per poco più di 10 euro spedito. Non è un fulmine di guerra, ma se si vuole avere un archivio centralizzato di film, magari con annesso serverino Upnp AV, tenuto su array raid 5, continua ad essere una ottima soluzione.
Peccato che tutta questa famiglia, basata su processori a 100Mhz (e quindi un po' scarsini come potenza di elaborazione), non possa utilizzare contemporaneamente la porta interna ed esterna dello stesso canale.
Se il controller è a doppio canale non è un problema, altrimenti bisogna scegliere se usare la "presa" esterna o quella interna!
Mettiamo che si decida di usare quella esterna, ad esempio per tenerci della macchine virtuali Vmware ESXi (ricordiamoci che ESX 3.5 o ESXi, che oltretutto è gratuito, possono bootare da drive PATA o SATA, ma non permettono di creare le macchine virtuali su quasi nessuno di essi, occorrono controller SCSI o SAS compatibili - vedi HCL sul sito Vmware).
Per meno di 30 euro, sempre con spedizione, ho trovato su Ebay un rack Promise UltraTrack JB4000. E' un affare che contiene 4 drive PATA in cassettini hot-swap, e li "converte" ad interfaccia scsi; il tutto contenuto in un rack da 1 unità, con raffreddamento, alimentazione, e due porte scsi 68 pin ad alta densità che permettono di impilare più unità, ognuna ovviamente col suo proprio ID scsi.
Se la performance non è un problema eccessivo eccovi un ottimo server ESXi che può contenere una appliance router virtuale (magari con VPN, antivirus, anti-intrusione, etc. come Untangle), una appliance SAN virtuale con supporto iScsi come ad esempio OpenFiler o FreeNAS, etc. etc. etc.
Se invece la performance è quello che cercate, specie nell'accesso random a piccoli files come nel caso di caricamento del S.O. oppure giochi con migliaia di files, si possono trovare delle bazze come un Seagate Cheetah 15K.4 da 147GB, nuovo, per poco più di 80 euro. Ovvio che bisogna sbattersi, e che non è tutto ora quel che luccica... ad esempio il mio Cheetah ha il firmware HP/Compaq, ed essendo un prodotto OEM Seagate non riconosce la garanzia (e siccome HP lo vendeva assieme a soluzioni integrate di storage, e non singolarmente, immagino che sia dura farsi accettare una RMA da HP!).
Per fortuna SeaTools Enterprise for Windows pur riconoscendolo come disco Compaq, permette di settarne i parametri, e quindi sono riuscito ad attivare la modalità Performance, adatta all'uso sopra descritto, mentre quella di default è la "server", per utilizzo ad alto I/O.
Avendo fatto un acquisto un po' alla cieca (avrei dovuto farmi dare la sigla esatta prima di comprare!), sono stato alla fine anche fortunato:
molti HD Seagate con firmware OEM (Dell, IBM, EMC, etc.) sono "taroccati" anche nell'hardware, e non solo nel firmware. C'è stato anche chi ha forzato il flashing del firmware originale Seagate perchè il disco era limitato al protocollo Ultra160, o per "armonizzarlo" in array complessi con gli altri HD che avevano firmware Seagate... col risultato di tirar fuori un bel costoso fermacarte! Anche se poi c'è chi ha raddoppiato, o addirittura quadruplicato, la capacità del proprio HD, perchè era stato "castrato" artificialmente; i Cheetah 15K.5 ad esempiohanno il piatto da 73GB, e se ne trovate una versione OEM dichiarata a 18Gb, ad esempio, vuol dire che col giusto firmware potrebbe diventare un 73GB. Dove trovare il "firmware giusto" invece è un grosso problema, visto che Segate fornisce il link per il download solo a chi possiede un "vero" seagate con tanto di seriale regolare.

Veniamo dunque al discorso performance, e a cosa mai potrebbe provocare lo strano comportamento che il mio Cheetah mostrava in tutti i benchmark che ho eseguito.
Detta in poche parole, aveva un curva piatta, ovvero rimaneva sempre sui 35MB di trasfer. Inizio o fine disco, lettura o scrittura, la banda era sempre + o - quella!
Siccome per farlo riconoscere a Seagate Tools Enterprise mi serviva connetterlo ad un controller non-raid, l'ho attaccato ad un adaptec 39160, che mi era stato consegnato free assieme al rack Promise di cui sopra.
Essendo una periferica non di boot avevo disabilitato il supporto al boot (INT 13), ed anche se allo scan che il controller effettuava all'avvio l'Hd veniva "visto" come Ultra160 (il controller come dice il nome non supporta l'Ultra320), i benchmark erano migliorati solo di pochissimo.
Quando ho provato ad abilitare il supporto al boot, e quindi ho potuto anche attivare l'opzione di Domain Validation, che è caratteristica peculiare proprio degli standard Ultra160 ed Ultra320, ho visto che il controller lo gestiva come 40MB 8-bit (invece che come 160MB 16-bit).
Trovata la ragione del problema! La banda passante era limitata a 40MB/sec, di qui le orribili performances fornite dal duo Adaptec 39160 + Cheetah 15K.4
Ma come rimediare?
Il cavo scsi era molto lungo, più di un metro, con nove connettori di cui 7 liberi, ma la marca (Amphenol Spectra-Strip) lasciava tranquilli. Oltretutto la cosa più importante, ovvero il terminatore, riportava un tranquillizzante sticker bianco con su scritto Ultra-160, mentre la copertura in plastica aveva stampato sopra LVD-SE. Tutto bene all'apparenza.
Però stranamente quando sostituisco per prova il cavo con uno meno blasonato, sempre marcato come compatibile Ultra160, le cose sono cambiate di colpo!
Il Domain Validation abilitava correttamente la comunicazione col disco a 160MB/sec 16-bit, ed i benchmark in ambiente Windows Server 2003 davano punte oltre i 105MB. L'accesso random ai files era come ovvio molto buono, ma questo succedeva anche con l'altro cavo... era solo la velocità del bus che limitava l'HD, specie nella lettura di files contigui o di grandi dimensioni.

la strana cosa è che le sigle del cavo Amphenol, su cui i produttori crimpano i vari connettori, sono le stesse che sono riportate all'inizio di questo thread!
E che in altre due occasioni, cercando negli archivi dei newsgroups, queste sigle sono associate ad una ridotta capacità di trasferimento degli HD scsi.
Molti indirizi fanno una prova:
per quanto possa sembrar strano, anche il cavo, pur di marca e fisicamente quasi identico ad altri, può dare grossi problemi di trasfer rate coi moderni dischi ad alta velocità di rotazione, anche se usati in modalità "single".
Non solo il terminatore quindi!
D'ora in poi starò ben attento a leggere la certificazione sulla piattina scsi a 68 poli, "liscia" o incrociata che sia, e non solo quello che c'è scritto sul terminatore!
Per il resto, scusate il lungo post, ma se qualcuno potrà avere come stimolo agli "acquisti scsi" gli esempi, strettamente personali ed abbastanza recenti, che ho sopra riportato, ne sarò lieto.
A volte capita che con pochi soldi in saccoccia, ma un po' si iniziativa, ci si possa permettere di sperimentare con strumenti che molti a torto considerano solamente "roba business". Oppure molto più semplicemente ci si possa permettere di avere un disco di boot che carica a manetta, magari anche meglio di quanto farebbe un carissimo e desideratissimo Velociraptor.

have fun

CJ

[dreaad]

riesumo questa discussione, ormai antica, per chiedere una piccola delucidazione, in merito al serveraid-4Lx, installato nella scheda madre in firma, con configurazione di 3 dischi fujitsu U320 da 147 GB RAID 0; il tutto installato in un mini rack per 3 dischi hot-swap in formato da 5.25" che supporta la modalitá U160.

anche io ho il problema di avere la banda piatta limitata a 40 MB/s , sia con raid 0 che singolarmente (provato HDTach e ATTO).
ho provato con cavo LVD con terminatore incorporato all'estremitá (classico bicolore bianco-arancione) che con cavo LVD senza terminatore, usando il terminatore sul rack.
niente di niente :( :( ...e non ci ho piú badato per tanto tempo, disilluso che non ne valesse ancora la pena perderci tempo.

poi ho letto questa discussione per caso e, spinto dalla curiositá, ho provato a cambiare lo slot PCI dove era installato il controller IBM.

quando l'ho reinstallato, il controller al check d'avvio restituisce codice errore FFFF - bios erased. sul manuale IBM dicono di utilizzare i download jumper per flashare firmware e bios nuovamente.

domanda: non trovo sul controller questi download jumper; vedo dei jumper di DEBUG e JTAG. potreste ragguagliarmi cortesemente?