slacky.eu

2 macchine con 2 HD SATA 1TB/32MB on-disk memory ognuna
Core 2 Dual 1866MHz 6320 con 4096kB L2 cache, 4GB main memory
Slackware 12.2 con ext2 quale FS, kernel statico 2.6.29.4

Sto testando da oltre 14 giorni vari compressori, magari postero` i risultati,
preparatevi xz 7.4 volte piu` veloce di gzip ... oops piu` lento.

Durante questi test ho notato una stranezza sulle 2 macchine:

ogni processore lavora un compressore su HD diverso,
secondo sar(1) ogni secondo sempre 0.00% idle,
se trasferisco files da HD1 a HD2 o viceversa,
i compressori stallano ... si incantano.

Come se la logica/memoria degli HD fosse incapace
di gestire due tasks alla volta (no multitasking).

Più che il disco credo che sia il controller i/o (southbridge) della motherboard.I dischi scrivono ciò che gli arriva nel buffer....

Mario ma ogni tanto potresti essere un po meno ermetico nelle tue descrizioni, ogni volta mi devo impengare per capire ........

kobaiachi ha scritto:Mario ma ogni tanto potresti essere un po meno ermetico nelle tue descrizioni, ogni volta mi devo impengare per capire ........

Compressore su HD1
sar dice 50% CPU
compressore su HD2
sar dice 100% CPU
copia ~1GB da HD1 a HD2 o viceversa
i compressori stallano

secondo slux
Più che il disco credo che sia il controller i/o (southbridge) della motherboard.I dischi scrivono ciò che gli arriva nel buffer....

ma dubito, provato su macchina simile,
con HD IDE 160GB/8MB mem on board,
gli stalli sono lunghi piu` del doppio

quindi la strettoia e` il disco!

Scusa Mario, ma secondo me arrivi a conclusioni sconclusionate.

Secondo il tuo ragionamento se io ho un solo HD non posso fare due copie in contemporanea, e quindi ad esempio non posso avere neanche due wget attivi in contemporanea. Non ti sembra un pò assurdo.

Secondo me ha ragione slux, l'HD scrive quello che gli viene detto di scrivere, quindi la soluzione al mistero potrebbe risiedere nella gestione degli HD da parte del kernel e conseguentemente della schedulazione dei processi che accedono in scrittura al disco.

Emanuele

Mario Vanoni ha scritto:

kobaiachi ha scritto:Mario ma ogni tanto potresti essere un po meno ermetico nelle tue descrizioni, ogni volta mi devo impengare per capire ........

Compressore su HD1
sar dice 50% CPU
compressore su HD2
sar dice 100% CPU
copia ~1GB da HD1 a HD2 o viceversa
i compressori stallano

secondo slux
Più che il disco credo che sia il controller i/o (southbridge) della motherboard.I dischi scrivono ciò che gli arriva nel buffer....

ma dubito, provato su macchina simile,
con HD IDE 160GB/8MB mem on board,
gli stalli sono lunghi piu` del doppio

quindi la strettoia e` il disco!

non ho capito, hai forse scoperto che, dato un disco qualsivoglia, il tempo di accesso non e' zero e la velocita' di trasferimento non e' infinita? bhe complimenti (sapevi che l'acqua e' bagnata?).

N.B. ovviamente il discorso non e' cosi' semplice e oltre al tempo di accesso e alla velocita' di trasferimento entrano in ballo un sacco di altre cose (controller, supporto NCQ o meno, scheduler di I/O, scheduler dei processi, ecc..) e non c'e' scalabilita' lineare; ma, visti i precedenti, per non confonderti non voglio fartela troppo complicata

spina ha scritto:Scusa Mario, ma secondo me arrivi a conclusioni sconclusionate.

Secondo il tuo ragionamento se io ho un solo HD non posso fare due copie in contemporanea,

dipende che intendi per copie

e quindi ad esempio non posso avere neanche due wget attivi in contemporanea.

certo che puoi averli, ma non scriveranno mai entrambi nello stesso istante sullo stesso disco

Non ti sembra un pò assurdo.

no, mi sembra la scoperta dell'acqua calda

spina ha scritto:Scusa Mario, ma secondo me arrivi a conclusioni sconclusionate.

Secondo il tuo ragionamento se io ho un solo HD non posso fare due copie in contemporanea, e quindi ad esempio non posso avere neanche due wget attivi in contemporanea. Non ti sembra un pò assurdo.

Secondo me ha ragione slux, l'HD scrive quello che gli viene detto di scrivere, quindi la soluzione al mistero potrebbe risiedere nella gestione degli HD da parte del kernel e conseguentemente della schedulazione dei processi che accedono in scrittura al disco.

Emanuele

Scusa Emanuele,
e` la gestione on-board degli HD, _non_ del kernel!

Sono gli HD che non supportano scrittura multipla,
nonostante tanta memory on-board!
Ma unicamente per risparmiare energia, non per efficienza!

La loro logica e` rimasta single task, non UNIX/Linux.
Sono curioso se trovo un WD2002FYPS 2TB/64MB in Italia.

Mario Vanoni ha scritto:...
Sono gli HD che non supportano scrittura multipla,
...

Per rispondere anche a masalapianta, cosa intendi con scrittura multipla?

Emanuele

Mario Vanoni ha scritto:Sono gli HD che non supportano scrittura multipla,
nonostante tanta memory on-board!

Mettiamola così Mario....meccanicamente la testina dell'HD non può trovarsi contemporanemente in due punti diversi del disco nello stesso istante....
ergo la scrittura contemporanea non esiste .

La gestione on-board dei dischi dipende dal DMA ,è vero, ma E' la cpu a coordinare i trasferimenti,chi decide cosa e quando deve essere trasferito, dipende sempre dallo scheduler del kernel.Magari hai il problema che viene dato tutta la priorità ad un solo task alla volta ,senza ripartire i tempi di esecuzione in maniera equa, e questo potrebbe essere un problema di scheduler,ma bisogna vedere anche come hai personalizzato il kernel....

masalapianta ha scritto: non ho capito, hai forse scoperto che, dato un disco qualsivoglia, il tempo di accesso non e' zero e la velocita' di trasferimento non e' infinita? bhe complimenti (sapevi che l'acqua e' bagnata?).

N.B. ovviamente il discorso non e' cosi' semplice e oltre al tempo di accesso e alla velocita' di trasferimento entrano in ballo un sacco di altre cose (controller, supporto NCQ o meno, scheduler di I/O, scheduler dei processi, ecc..) e non c'e' scalabilita' lineare; ma, visti i precedenti, per non confonderti non voglio fartela troppo complicata

Infatti, vent'anni fa` in una ditta amica,
il capo ed il suo programmatore, UNIX (esix, se ricordo bene),
dischi SCSI con 16kB di memoria on-board,
disattivavano la on-board memory, possibile allora,
per avere scrittura su HD in RT (tempo reale),
simile a fare un "sync ; sync ; sync" oggi,
anche se oggi e` pura illusione, il kernel comanda, ma ...
il disco fa poi quello che vuole lui e quando vuole lui.

spina ha scritto:

Mario Vanoni ha scritto:...
Sono gli HD che non supportano scrittura multipla,
...

Per rispondere anche a masalapianta, cosa intendi con scrittura multipla?

Emanuele

Che la logica/memoria del disco faccia il suo lavoro in RT,
in ordine come comandato, scrittura/lettura,
che non tenga in memoria una scrittura finche'
non ci sia una lettura/scrittura vicina/o la sua memoria esausta.

Che i dischi attuali facciano un pò schifo come affidabilità é noto ... ma che siano lenti e poco performanti mi sembra molto strano ...
Tanto per rimanere intema di affidabilità vi rendo noto che Seagate-Maxtor in caso di guasto vi sostituisce il disco con un disco rigenerato che sono identici ai nuovi ma hanno un adesivo con la righina verde ... invece che blu.
Diffidate da queste schifezze sono vere mine vaganti e prima o poi scoppieranno, a un mio amico ne hanno mandato uno con il piatto sballato e appoggiato su un piano camminava! ... prima di utilizzarli fategli fare un burning test ... o portateli allo smaltimento guadagnerete in salute ... e sempre se ci tenete alla salute ... evitate di comprare Seagate e Maxtor almeno fino a che non torneranno a fare un assistenza degna di questo nome!

EDIT: ecco i dischi sicuramente deficienti

slux ha scritto:...E' la cpu a coordinare i trasferimenti,chi decide cosa e quando deve essere trasferito...

Vero, ma essa da istruzioni al controller che gestisce gli hard disks, in sostanza, gli passa "la patata bollente";
da qui, il flusso dati viene "smistato" verso il disco di destinazione ed ulteriormente gestito dalla logica a bordo di quest'ultimo, per poi esser scritto finalmente sul supporto magnetico.
Dalla mia esperienza, non poche volte ho incontrato problemi eseguendo operazioni pesanti di trasferimento dati, specie se da un disco ad un altro.
La maggior parte delle volte il problema stava nel supporto del kernel per il controller usato.
L'ultimo che mi viene in mente:
Freeze del kernel durante la creazione di un file tar compresso con gzip, da md0 (raid) ad unità disco interna a scopo backup (sdc).
Se non si verificava il "freeze", comunque, l'operazione era impietosamente lunga.
In questo caso il problema fu sul supporto al controller SATA (un Marvell) da parte del kernel (mi pare fosse un 2.6.27.*), supportato ma (HIGHLY EXPERIMENTAL).
Un' altra volta, stesso problema, con la differenza che il controller era supportato in pieno dal kernel. Cambiai controller (con uno che sapevo funzionante 100% linux),
nessun problema. Aspettai di trovare modifiche sul changelog del kernel riguardo al mio controller on-board per poi tornare ad utilizzarlo senza problemi.

Raramente inoltre, può capitare che un certo controller non voglia comunicare decentemente con la logica di un certo hard disk (peraltro, sui changelog di alcuni aggiornamenti firmware/BIOS,
talvolta si notano voci riguardo ad aggiunte di supporto a quello od altro hard disk, forse non è poi così infrequente).

Saluti,
MuRdOcK

spina ha scritto:

Mario Vanoni ha scritto:...
Sono gli HD che non supportano scrittura multipla,
...

Per rispondere anche a masalapianta, cosa intendi con scrittura multipla?

Emanuele

bhe lui aveva scritto "Come se la logica/memoria degli HD fosse incapace
di gestire due tasks alla volta (no multitasking)." e io l'ho interpretato come "un disco non puo' effettuare piu' di un'operazione di scrittura/lettura per volta" (il che e' la scoperta dell'acqua calda come ho detto)