Newsgroup: it.comp.os.linux.sys
Titolo: Prestazioni RAID software *deludenti*!

 Se pensi che sia troppa roba per il NG, mandameli pure in privato.
Mandato tutto nella tua casella, rispondimi qui però :-)
Bye

 Mandato tutto nella tua casella, rispondimi qui pero` :-)
Ok: il 82371AB  dispone di una doppia FIFO. Dai dati  che mi hai mandato
si vede che hai la prima revisione  del SB (risalente al maggio del 98),
mentre  l'ultima  disponibile  e`  la sesta. Potrebbe  anche  essere  un
problema del chipset (ma non penso...). Il BM e` corrattamente attivato,
ed i timing sembrano corretti. Spicca pero` il trasferimento impostato a
16 bit e il non-mascheramento degli IRQ durante l'attivita` del disco.
Io consiglio:
Attivare i trasferimenti a 32 bit ed il mascheramento:
hdparm -u1 -c1 /dev/hda
hdparm -u1 -c1 /dev/hdc
Ripetere i test con hdparm. Se i risultati rimangono uguali (non penso),
prova ad effetture la prova su dischi bypassando il layer RAID:
hdparm -tT /dev/hda & hdparm -tT /dev/hdc
In questo modo i test dovrebbero andare in parallelo.
Se noti dei miglioramenti la colpa e` del layer RAID. Soluzione: passare
ad una Epox 8K3A+ con controller RAID integrato ;)
Se  rimane tutto  come prima  prova a  passare al  kernel 2.4.19-ac4. Ho
visto che  ci sono  dei cambiamenti  consistenti nell'autoconfigurazione
dei PIIX.
Se  neppure questo  funziona, chiedi  ad Andre  Hedrick spiegazioni  sul
commento  presente  in driver/ide/piix.c:196. Nella  documentazione  non
c'e` traccia di questa fantomatica opzione.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"La mia teoria scientifica preferita e` quella secondo la quale gli 
 anelli di Saturno sarebbero interamente composti dai bagagli andati 
 persi nei viaggi aerei." -- Mark Russel

 c'e` traccia di questa fantomatica opzione.
Non capisco nulla di C, comunque ho visto il commento e sotto un... una 
variabile settata a "0" ???
Bye e grazie mille!
Ciao

 variabile settata a "0" ???
Si`, il fatto e` che quella variabile non c'entra nulla con il commento,
che non capisco a cosa sia riferito. Potrebbe anche essere un residuo di
vecchio codice... boh
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Se non sei parte della soluzione, allora sei parte del problema.

 vecchio codice... boh
Ahz, comunque sto compilando il 2.4.19-ac4 con tanto di
ATA EXPERIMENTAL (WORK IN PROGRESS)
abilitato. Speriamo in bene :-)))
Ciao

 [sab, 10 ago 2002 at 18:52 GMT]:
[...]
Nada, non è cambiato nulla :(((
E' il controller? E' la tua risposta definitiva? L'accendiamo?
Bye e tnx

 Attivare i trasferimenti a 32 bit ed il mascheramento:
Il mascheramento peggiora le prestazioni dell'HD,
in generale, in quanto aumenta la latenza di
risposta all'interrupt (migliora la risposta di
tutto il sistema).
Non saprei se migliora o peggiora la situazione
nel caso si usino due HD in parallelo.
bye,
-- 
piergiorgio

 Timing buffered disk reads:  64 MB in  4.74 seconds = 13.50 MB/sec
Hum, sembra che si spartiscano la banda...
Lettura interessante:
http://research.microsoft.com/BARC/Sequential_IO/IDE_Performance_Report.doc
sembra  che  la  latenza  sul  bridge  sia  molto  alta,  inoltre  viene
evidenziato  un   degrado  delle   prestazioni  utilizzando  due   HD  e
trasferimenti di piu` di 16KB. Viene comunque riscontrato un aumento del
tput utilizzando due dischi in parallelo.
Tornando alla  FIFO, i  dati che avevo  trovato facevano  riferimento al
82371AB/EB,  sul  tuo controller  non  c'e`  traccia di  "EB". Sul  sito
dell'Intel  non ho  trovato  notizie  affidabili: il  BX  viene dato  in
accoppiata con 82371AB/EB...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
K.R.O.N.O.S
Kinetic Replicant Optimized for Nocturnal Observation and Sabotage

 tutto il sistema).
Hai ragione, va un po meglio!
Ciao
ps: Ormai ho deciso, cerco un Promise ATA100 usato per pochi soldi e ci
attacco gli HDD. Spendere 50EUR per prenderlo nuovo no, ma usato per
25/30 penso valga la pena. Tanto poi verso gennaio cambierò mobo. 

 accoppiata con 82371AB/EB...
Ok, ormai penso non ci siano + dubbi, prenderò un ctrl ATA100 usato.
Grazie molte per l'interessamento.
Bye

 risposta all'interrupt 
No, e` il  contrario. Il mascheramento viene fatto mentre  il kernel sta
servendo  un interrupt  generato dal  disco. Quindi gli  altri interrupt
(anche di priorita` piu` elevata) vengono accodati.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"New processes are created by other processes, just like new
 humans. New humans are created by other humans, of course,
 not by processes." -- Unix System Administration Handbook

 migliora.... magari XFS in RAID non va bene.... bho....
Sulla ML ( di xfs ) si suggerisce di mettere il log in un altro disco, pena 
pesanti degradamento delle prestazioni

 pesanti degradamento delle prestazioni
Grazie dell'info, putroppo pero` ho usato da quasi-subito reiser e le
prestazioni del raid non sono cambiate :-(
Ciao

> pena pesanti degradamento delle prestazioni
Mi sono dimenticato di aggiungere sui sistemi RAID
