[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