View previous topic :: View next topic |
Author |
Message |
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Mon Apr 25, 2005 2:15 pm Post subject: cp LENTISSIMO su trasferimenti verso penna USB [RISOLTO] |
|
|
Ho
* penna USB 1.1 da 128 Mb FAT32, montata con "noauto,noatime,user,sync,rw,exec"
* partizione reiserfs v3 con opzioni "noatime"
* linux-2.6.11-gentoo.
Ho provato a copiare un unico file da 34Mb dalla partizione reiserfs alla penna USB:
Con KDE: 50 secondi (~ 696 kB/s)
Con cp: 254 secondi (~ 137 kB/s)!!!
Com'è possibile???
Copiando un file da 670 Mb dalla partizione ReiserFS su sé stessa ci mette più o meno lo stesso tempo, ma ovviamente qui contano le prestazioni del disco fisso. _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied
Last edited by CRV§ADER//KY on Tue Apr 26, 2005 10:08 am; edited 1 time in total |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4810 Location: http://www.gentoo-users.org/user/cloc3/
|
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Mon Apr 25, 2005 2:29 pm Post subject: |
|
|
Non uso /dev/ub*. L'ho appena tolto; ora la chiave è su /dev/sda1. Prima tutte le applicazioni andavano esattamente a 64k/s. _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4810 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Mon Apr 25, 2005 2:38 pm Post subject: |
|
|
CRV§ADER//KY wrote: | Non uso /dev/ub*. L'ho appena tolto; ora la chiave è su /dev/sda1. Prima tutte le applicazioni andavano esattamente a 64k/s. |
Ma sei ben sicuro di aver anche rimosso il modulo dal kernel? Come spiegava Fonderia nel secondo post, viene caricato di default quando non dovrebbe. _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Mon Apr 25, 2005 2:40 pm Post subject: |
|
|
Sì, quel modulo non esiste più nel mio kernel, l'ho completamente deselezionato e ho verificato con lsmod che non venga caricato. _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
xchris Advocate
Joined: 10 Jul 2003 Posts: 2824
|
Posted: Tue Apr 26, 2005 8:51 am Post subject: |
|
|
ho notato la stessa cosa sul ipod shuffle (che e' sempre una chiave usb)
togliendo il sync la velocita' e' aumentata notevolmente.
(chiaramente devi ricordarti l'unmount.... altrimenti al 99% dei casi non salvi un bel tubo
Nota: i tempi si sono decuplicati e nei tempi ho incluso anche l'unmount del device!
ciao _________________ while True:Gentoo() |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Tue Apr 26, 2005 8:57 am Post subject: |
|
|
xchris wrote: | ho notato la stessa cosa sul ipod shuffle (che e' sempre una chiave usb)
togliendo il sync la velocita' e' aumentata notevolmente.
|
Cioé con alcuni programmi andava rapido e con altri no? Oppure era lento con tutti? la l'iPod Shuffle non é un USB2?
CRV§ADER//KY, sei sicuro che KDE usi l'opzione sync?
Quote: | Nota: i tempi si sono decuplicati e nei tempi ho incluso anche l'unmount del device! |
I tempi si sono decuplicati quando hai aggiunto sync, suppongo.... _________________ Ciao da me! |
|
Back to top |
|
|
xchris Advocate
Joined: 10 Jul 2003 Posts: 2824
|
Posted: Tue Apr 26, 2005 9:25 am Post subject: |
|
|
randomaze wrote: |
Cioé con alcuni programmi andava rapido e con altri no? Oppure era lento con tutti? la l'iPod Shuffle non é un USB2?
|
si... USB2
dei semplici cp... oppure gtkpod!
Quote: |
I tempi si sono decuplicati quando hai aggiunto sync, suppongo.... |
assolutamente no...
togliendo sync e' diventato una scheggia! (umount compreso...ovviamente) _________________ while True:Gentoo() |
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Tue Apr 26, 2005 10:06 am Post subject: |
|
|
ho montato la penna con async e ho fatto:
date && cp bigfile.mp3 /mnt/usbpen/ && umount /mnt/usbpen/ && date
Ci ha messo 43 secondi (~ 810 kB/s). Grande!
Morale: cp è bacato e non supporta bene i device lenti. _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Tue Apr 26, 2005 10:09 am Post subject: |
|
|
randomaze wrote: | CRV§ADER//KY, sei sicuro che KDE usi l'opzione sync? |
Sì sono sicuro, il mount lo faccio a mano, non usando KDE. _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Tue Apr 26, 2005 10:31 am Post subject: |
|
|
CRV§ADER//KY wrote: | Morale: cp è bacato e non supporta bene i device lenti. |
Beh in realtà più che di baco penso che il tutto dipende da quante operazioni di scrittura fa cp e quante ne fa konquerror (o altro).... _________________ Ciao da me! |
|
Back to top |
|
|
xchris Advocate
Joined: 10 Jul 2003 Posts: 2824
|
Posted: Tue Apr 26, 2005 11:06 am Post subject: |
|
|
e' molto strano..
in teoria nulla e' + semplice e diretto di un cp... _________________ while True:Gentoo() |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Tue Apr 26, 2005 11:37 am Post subject: |
|
|
xchris wrote: | in teoria nulla e' + semplice e diretto di un cp... |
dato che la copia di un file dovrebbe essere fatta leggendo X dati da un file e scrivendo X dati su un'altro, suppongo che copiare un file di 34 Mega in un solo passaggio (con X=34M) oppure in 34000 (con X=1k) sia abbastanza differente ai fini del sync _________________ Ciao da me! |
|
Back to top |
|
|
xchris Advocate
Joined: 10 Jul 2003 Posts: 2824
|
Posted: Tue Apr 26, 2005 12:11 pm Post subject: |
|
|
se consideri sempre l'unmount..
in linea teorica i tempi non dovrebbero essere paragonabili?
(supponi di avere un sistema con sufficiente RAM)
oppure non ti ho capito _________________ while True:Gentoo() |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Tue Apr 26, 2005 12:17 pm Post subject: |
|
|
xchris wrote: | se consideri sempre l'unmount..
in linea teorica i tempi non dovrebbero essere paragonabili? |
Si dovrebbero, ma dipende da come é fatto il sync... per quello che posso dire (parlando a scatola chiusa) potrebbe, ad esempio, per ogni scrittura elementare aspettare che il buffer venga svuotato se non addirittura disabilitarlo, mentre l'unmount lo verificherebbe alla fine e una sola volta. _________________ Ciao da me! |
|
Back to top |
|
|
xchris Advocate
Joined: 10 Jul 2003 Posts: 2824
|
Posted: Tue Apr 26, 2005 12:25 pm Post subject: |
|
|
cmq e' strano un divario di prestazioni cosi' evidente...
mboh _________________ while True:Gentoo() |
|
Back to top |
|
|
gutter Bodhisattva
Joined: 13 Mar 2004 Posts: 7162 Location: Aarau, Aargau, Switzerland
|
Posted: Wed Apr 27, 2005 4:07 pm Post subject: |
|
|
randomaze wrote: |
Si dovrebbero, ma dipende da come é fatto il sync... per quello che posso dire (parlando a scatola chiusa) potrebbe, ad esempio, per ogni scrittura elementare aspettare che il buffer venga svuotato se non addirittura disabilitarlo, mentre l'unmount lo verificherebbe alla fine e una sola volta. |
Da quello che ho letto io il sync opera a livello sw e non hw, nel senso che poi sarà l'HD a decidere quando effettivamente scrivere i dati dal buffer sui piatti.
O non ho capito quello che volevi dire? _________________ Registered as User #281564 and Machines #163761 |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Wed Apr 27, 2005 5:08 pm Post subject: |
|
|
gutter wrote: | Da quello che ho letto io il sync opera a livello sw e non hw, nel senso che poi sarà l'HD a decidere quando effettivamente scrivere i dati dal buffer sui piatti.
O non ho capito quello che volevi dire? |
Hai capito... salvo che sulle chiavette non ci sono piatti
mumble mumble.... _________________ Ciao da me! |
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Wed Apr 27, 2005 5:22 pm Post subject: |
|
|
Funziona così:
Con l'opzione sync, le write() bloccano il programma finché il device non è di nuovo pronto a ricevere dati.
Con l'opzione async (default), le write() operano su un buffer del kernel e, finché questo non si è completamente riempito, la velocità di scrittura è pari a un accesso in RAM. Il buffer viene svuotato in maniera asincrona; se viene fatta una richiesta di unmount, essa viene bloccata finché tutto il buffer non è stato svuotato. Per contro, se il device non viene smontato correttamente (es. floppy chiavi USB device di rete) rischi di perdere dati, in quanto le scritture possono non essere ancora avvenute, anche se l'applicazione in user space ha già concluso le sue chiamate a write() da un pezzo.
Questo non ha nulla a che fare con un'eventuale cache interna del device (es. hard disk), che è attiva sia con sync sia con async.
cp evidentemente "percepisce" la velocità del device e si regola di conseguenza - ma lo fa in modo erroneo. Con l'opzione async attivata, dal punto di vista di cp la velocità della chiave è di alcune decine di MB/s.
L'alternativa è che ci sia:
while (!finished)
{
write(SEGMENT_SIZE);
malloppo di codice pesantissimo
}
In questo modo, con async il malloppo verrebbe eseguito durante la scrittura, mentre con sync tra una scrittura e l'altra. Anche se, francamente, non vedo come possa giustificare un calo di prestazioni del 500% su un Athlon 2000+.... _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
gutter Bodhisattva
Joined: 13 Mar 2004 Posts: 7162 Location: Aarau, Aargau, Switzerland
|
Posted: Wed Apr 27, 2005 10:08 pm Post subject: |
|
|
randomaze wrote: |
Hai capito... salvo che sulle chiavette non ci sono piatti
mumble mumble.... |
Chiaro
il mio era solo un discorso generale sull'opzione sync _________________ Registered as User #281564 and Machines #163761 |
|
Back to top |
|
|
randomaze Bodhisattva
Joined: 21 Oct 2003 Posts: 9985
|
Posted: Thu Apr 28, 2005 12:42 pm Post subject: |
|
|
gutter wrote: | il mio era solo un discorso generale sull'opzione sync |
Comunque giusto per levarmi lo sfizio ho fatto andare questo possente test di benchmarking:
Code: |
#!/bin/bash
mount -o sync -t vfat /dev/pen1 /mnt/pendrive/ && \
#cp /usr/portage/distfiles/qt-x11-free-3.3.4.tar.bz2 /mnt/pendrive/test/ && \
#dd if=/usr/portage/distfiles/qt-x11-free-3.3.4.tar.bz2 of=/mnt/pendrive/test/test.out bs=10000000 && \
dd if=/usr/portage/distfiles/qt-x11-free-3.3.4.tar.bz2 of=/mnt/pendrive/test/test.out bs=512 && \
umount /mnt/pendrive
|
Con i seguenti risultati:
Code: |
###
### Test Case: cp /.../qt-x11-free-3.3.4.tar.bz2 /mnt/pendrive/test/
###
trider test # time ./speedtest.sh
real 0m5.774s
user 0m0.015s
sys 0m0.446s
trider test # time ./speedtest-without-sync.sh
real 0m2.467s
user 0m0.006s
sys 0m0.172s
###
### Test Case: dd if=/.../qt-x11-free-3.3.4.tar.bz2 of=/mnt/pendrive/test/test.out bs=10000000
###
# time ./speedtest.sh
1+1 records in
1+1 records out
real 0m2.470s
user 0m0.001s
sys 0m0.171s
# time ./speedtest-without-sync.sh
1+1 records in
1+1 records out
real 0m2.464s
user 0m0.002s
sys 0m0.181s
###
### Test Case: dd if=/.../qt-x11-free-3.3.4.tar.bz2 of=/mnt/pendrive/test/test.out bs=512
###
# time ./speedtest.sh
28202+1 records in
28202+1 records out
real 0m17.359s
user 0m0.038s
sys 0m2.772s
trider test # time ./speedtest-without-sync.sh
28202+1 records in
28202+1 records out
real 0m2.478s
user 0m0.011s
sys 0m0.203s
|
_________________ Ciao da me! |
|
Back to top |
|
|
CRV§ADER//KY Guru
Joined: 30 Aug 2004 Posts: 405 Location: Torino
|
Posted: Thu Apr 28, 2005 1:00 pm Post subject: |
|
|
Quote: | real 0m17.359s
user 0m0.038s
sys 0m2.772s |
Interessante.... i 2 secondi extra di CPU sys sono giustificati dal maggior numero di chiamate a write(), ma.... i 13 secondi rimenenti???
Questo fa cadere la mia seconda ipotesi, quella del "malloppo" di codice (il tempo CPU utente è invariato e quello kernel aumenta di poco).
IMHO il problema di cp è che regola male il block size in base alla velocità percepita del drive.
Resta da vedere come mai il kernel rallenta così tanto con block size piccolo, visto che l'incremento di CPU non è significativo...
Fosse un disco fisso direi che in mezzo il disco fa altra roba, fa seek etc, ma è una penna USB! quindi il tempo di seek = 0 e quello di accesso dovrebbe essere quasi zero (il tempo di decodificare la richiesta USB). _________________ Kyrie, Ignis Divine, Eleison ~ Elfen Lied |
|
Back to top |
|
|
Onip Advocate
Joined: 02 Sep 2004 Posts: 2912 Location: Parma (Italy)
|
Posted: Thu Apr 28, 2005 2:18 pm Post subject: |
|
|
una domanda. (@mod ditemi se è meglio se apro un altro thread)
a me l'opzione sync la mette automaticamente fstab-sync quando attacco la chiavetta. Qualcuno sa come fare per impedirglielo? Io ho creato un no_sync.fdi copiando la parte relativa a sync nel .fdi di default e mettendo le voci a false. il file l'ho messo in 50user/, cosicchè lo leggesse prima dei default, manon funziona. Sono andato poi a modificare il file di default in 90defaultpolicy e adesso funziona. Qualche idea? _________________ Linux Registered User n. 373835
Titus Lucretius Carus, De Rerum Natura - Tantum religio potuit suadere malorum |
|
Back to top |
|
|
Onip Advocate
Joined: 02 Sep 2004 Posts: 2912 Location: Parma (Italy)
|
Posted: Tue May 03, 2005 8:07 am Post subject: |
|
|
up _________________ Linux Registered User n. 373835
Titus Lucretius Carus, De Rerum Natura - Tantum religio potuit suadere malorum |
|
Back to top |
|
|
|