[Linux-bruxelles] USB - aMule - clef USB
Benoît Louveaux
benoit.louveaux at gmail.com
Mer 7 Avr 19:37:27 CEST 2010
On 07/04/10 17:46, Serge SMEESTERS wrote:
> Salut,
>
> En gros, le taux de transfère dépend énormément de choses. Voici
> celles auxquels je pense :
>
> Le périphérique USB n'est peut-être pas seul sur son contrôleur.
> La bande passante serait alors partagée à son désavantage.
> La commande à utiliser pour savoir, c'est lsusb
> Chez moi :
OK. Il semble que 'aMule' (Western Digital) et 'cp' (Kingston) soient
sur le même contrôleur :
[didier at localhost ~]$ sudo lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 1058:1003 Western Digital Technologies, Inc.
Bus 004 Device 004: ID 0951:1625 Kingston Technology
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 1bcf:0007 Sunplus Innovation Technology Inc.
didier at localhost ~]$ sudo lsusb -t
Bus# 5
`-Dev# 1 Vendor 0x1d6b Product 0x0001
`-Dev# 2 Vendor 0x1bcf Product 0x0007
Bus# 4
`-Dev# 1 Vendor 0x1d6b Product 0x0002
|-Dev# 2 Vendor 0x1058 Product 0x1003
`-Dev# 4 Vendor 0x0951 Product 0x1625
Bus# 3
`-Dev# 1 Vendor 0x1d6b Product 0x0001
Bus# 2
`-Dev# 1 Vendor 0x1d6b Product 0x0001
Bus# 1
`-Dev# 1 Vendor 0x1d6b Product 0x0001
Mais ceci ne me semble pas expliquer l'ENORMITE des lenteurs !!!!! Pour
exemple, il me faut +/- 30 secondes pour afficher un Xterm !!! (les
bianires ne sont PAS sur USB, mais sur ATA !!)
La commande 'df', elle aussi est surprenante : elle bloque durant +/- 60
secondes sur la ligne 'Kingston' : le strace doone dans les dernières
lignes :
statfs64("/home/didier/.gvfs", 84, {f_type=0x65735546, f_bsize=4096,
f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0},
f_namelen=1024, f_frsize=4096}) = 0
statfs64("/media/disk", 84, {f_type="MSDOS_SUPER_MAGIC", f_bsize=16384,
f_blocks=6101215, f_bfree=6101214, f_bavail=6101214, f_files=0,
f_ffree=0, f_fsid={2065, 0}, f_namelen=260, f_frsize=16384}) = 0
write(1, "/dev/sdb1 97619440 "..., 68/dev/sdb1
97619440 16 97619424 1% /media/disk
) = 68
statfs64("/media/KINGSTON", 84,
... Prenez des dizaines de secondes de patience ...
{f_type=0x65735546, f_bsize=4096, f_blocks=1957613, f_bfree=1148017,
f_bavail=1148017, f_files=4624836, f_ffree=4624812, f_fsid={0, 0},
f_namelen=255, f_frsize=4096}) = 0
write(1, "/dev/sdc1 7830452 "..., 72/dev/sdc1
7830452 3238384 4592068 42% /media/KINGSTON
) = 72
close(1) = 0
munmap(0xb775e000, 4096) = 0
close(2) = 0
exit_group(0) = ?
En bref, je ne vois pas pourquoi un "conflict" entre aMule et cp
pourraient ralentir à ce point tout le système Linux ...
P.S. Avant de tester une quelconque permutation des ports USB, je vais
attendre que la copie soit terminée ... Peut-être que vers minuit ????
Merci.
Plus d'informations sur la liste de diffusion Linux-bruxelles