Pincho USB lentísimo [¡¡Resuelto!!]

A ver si me podéis arrojar luz, porque no sé que puede pasar.

El jueves pasado le cambié a mi equipo la placa y el micro, porque cacharreando me había cargado mi micro antiguo. Hice el cambio de hardware, arranqué mi debian y en principio no me funcionaba la tarjeta de sonido. Actualicé el núcleo del 2.6.26 que lleva por defecto squeeze a un núcleo 2.6.30 y la cosa quedó resuelta. El caso es que ayer intentado pasar una iso de unos 600 MB a un pincho USB, me desesperé de la lentitud con que se transferían el archivo. Hice la siguiente prueba (que no sé lo veraz que será):

cat imagen.iso | pv > /media/PINCHO/imagen.iso


Y el pv me decía que la transferencia rara vez pasaba de los 200KB/s, que es una miseria. Haced cuentas: salen unos 50 minutos para transferir el archivo. Y, efectivamente, aquello tardó mas de una hora porque en realidad la velocidad media eran unos 170KB/s.

No sé si será que el USB de la placa está mal soportado o qué narices. Datos a tener en cuenta:

$ lspci | grep USB
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)


$ lsmod | grep "usb\|hci"
usbhid                 37328  0
hid                    41376  1 usbhid
usb_storage            61600  2
scsi_mod              158768  6 firewire_sbp2,sg,sr_mod,sd_mod,usb_storage,libata
uhci_hcd               22208  0
firewire_ohci          22356  0
firewire_core          44980  2 firewire_sbp2,firewire_ohci
ehci_hcd               33996  0


¿Esto qué significa exactamente?:

dmesg | grep speed
[    0.896508] usb 1-1: new high speed USB device using ehci_hcd and address 2
[    2.056008] usb 5-1: new low speed USB device using uhci_hcd and address 2



Este error me escama:

dmesg | grep hda_intel
[    6.272006] hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
[    7.276010] hda_intel: Codec #0 probe error; disabling it...


He hecho la prueba con mi antiguo núcleo 2.6.26 y pasa exactamente lo mismo.

¿Alguna idea?
eso me pasaba en mi pincho. pero descubri que era cosa del ntfs-3g (100%de uso de cpu)
sL1pKn07 escribió:eso me pasaba en mi pincho. pero descubri que era cosa del ntfs-3g (100%de uso de cpu)


No, eso no es, gracias, el pincho está formateado en fat32:

/dev/sdb2 on /media/LAPIZ type vfat (rw,nosuid,nodev,sync,uhelper=hal,uid=1000)


Probé con otro pincho de todos modos y el rendimiento era similar.

Y en mi disco duro, por supuesto, no hay ni rastro de sistemas ntfs o fat.

EDITO porque he averiguado algo más. El pincho lo monto automáticamente con halevt, porque ivman que es lo que antes usaba, un buen día dejó de funcionar. Si lo monto a mano con el mount de toda la vida, el problema desaparece. :-?
auxiliar escribió:Si lo monto a mano con el mount de toda la vida, el problema desaparece. :-?

Y si lo montas a mano, tambien te lo monta con la opcion Sync?
JanKusanagi escribió:
auxiliar escribió:Si lo monto a mano con el mount de toda la vida, el problema desaparece. :-?

Y si lo montas a mano, tambien te lo monta con la opcion Sync?


¡Joder! ¡Qué ojo! No...

/dev/sdb1 on /mnt/loop type vfat (rw)


...Y esa es la causa.

Analicemos:

cubolleta:~# ls -lh /mnt/virtual/mover/Exploration1.zip
-rw-r--r-- 1 usuario kvm 103M oct 12 22:20 /mnt/virtual/mover/Exploration1.zip


O sea, voy a hacer la prueba con un fichero de unos 100MB.

Con sync:

cubolleta:~# mount -o sync /dev/sdb1 /mnt/loop/
cubolleta:~# time cat /mnt/virtual/mover/Exploration1.zip > /mnt/loop/E1a.zip
^C

real    6m15.489s
user    0m0.000s
sys     0m0.084s


Me he cansado de esperar. A los 6 minutos lleva:

cubolleta:~# ls -lh /mnt/loop/E1a.zip
-rwxr-xr-x 1 root root 29M oct 14 00:34 /mnt/loop/E1a.zip


¡29 MB!

Ahora sin sync:

cubolleta:~# umount /mnt/loop
cubolleta:~# mount /dev/sdb1 /mnt/loop/
cubolleta:~# time (cat /mnt/virtual/mover/Exploration1.zip > /mnt/loop/E1a.zip && sync)

real    0m20.119s
user    0m0.000s
sys     0m0.196s
cubolleta:~# ls -lh /mnt/loop/E1a.zip
-rwxr-xr-x 1 root root 103M oct 14 00:37 /mnt/loop/E1a.zip


Listo en apenas 20 segundos.

¿Tanta diferencia hay entre montarlo con la opción sync o hacer el sync al final?

Ya lo he arreglado: he quitado esa opción del fichero de configuración /etc/hdalevt/halevt.xml y:

/dev/sdb1 on /media/Debian Inst type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000)
/dev/sdb2 on /media/LAPIZ type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000)


$ time (cat /mnt/virtual/mover/Exploration1.zip > /media/Debian\ Inst/E1a.zip && sync)

real    0m18.712s
user    0m0.000s
sys     0m0.172s


Muchas gracias
(mensaje borrado)
Aprovecho que alguien borró para añadir algo de información. Parece ser que el problema surge con la opción sync y el sistema de ficheros vfat. Al menos, por lo que he leído en esta antigua entrada de unos foros de gentoo. He probado a formatear un pincho en ext3, que me lo montase halevt con la opción sync, y la transferencia de archivos se hacía a buena velocidad. A ver si logro configurar el halevt para que no incluya la opción sync solamente cuando el sistema de ficheros a montar es vfat.
Soy bastante novato y no entiendo lo que comentáis pero, antes de ponerme a "empoyar" para enterarme de lo que habláis, os quiero preguntar lo siguiente.

Desde una actualización (uso arch), resulta que al montar un disco duro externo (formateado en fat32 para que lo lea el dvd de casa) tarda MUCHO en montarlo. Otros formateados en otros formatos (aunque algo más pequeños) los monta de manera inmediata.

Quería preguntaros si es posible que sea consecuencia de un problema similar.
Gracias!
7 respuestas