USB masstorage

10 sujets de 1 à 10 (sur un total de 10)

Gilloo
14 juin 2011 à 14h13 #9723
déçu :'(

Entre 6KB/s et 11KB/s à peine (ANAIIS massive + 68000@7,14MHz).

SysInfo me dit 1900KB/s et Diskspeed me donne un débit <1 octet par seconde.

Il y a-t-il un moyen pour améliorer ce truc…
mrodfr
14 juin 2011 à 15h45 #149451
Salut,

Histoire de rebondir sur ce sujet.

Mon debian sur SAM est passé d’un USB rapide a un USB lent (avec la meme clé USB 16go) pour la copie sur medias flash genre clé USB ou baladeur MP3.

La copie de fichier part vite puis ralentit a une vitesse tres tres lente.

Ca marchait bien (copie 30mo/s toujours) puis le probleme est apparu apres quelques MAJ du systeme.

En cherchant sur google, on trouve pas mal de fois ce sujet sur tous les linux avec beaucoup de difficultées pour trouver une solution mais a un moment on parle d’une option sync.

http://linuxfr.org/forums/linuxg%C3%A9n%C3%A9ral/posts/synchronisation-avec-unison

tout ceci pour dire que dans ton cas, peut etre tu ecris en mode lent (puisqu’il y a apparemment un mode nosync, flush et sync sur Linux avec les cles et autres medias USB).

no sync (rapide), flush (moyen), sync (lent).

Ceci juste pour dire que j’ai pas encore essayé cette methode (modifier usbmount.conf sous debian et y enlever sync) mais peut etre cela peut il avoir un rapport avec ta question (ou pas)
Tiki
14 juin 2011 à 16h21 #149452
30 Mo/sec… C’est extrêment rapide çà…

Quand j’ai une clef que je commence à trouver lente, un simple formatage suffit souvent a résoudre le problème.

Tiki
Gilloo
14 juin 2011 à 16h33 #149453
heu… ce ne serait pas tout simplement la différence entre FAT32 et NTFS ? FAT sans cache et NTFS avec cache ?

mais bon le jour ou mon A2000 lira des partitions NTFS, je boufferais les pissenlits par la racine…
mrodfr
14 juin 2011 à 18h59 #149454
Non,

c’est plutot 3 facons pour la gestion de peripheriques USB FAT32 en memoire flash (clé, baladeur,…) sur linux.

un mode qui economise la memoire flash, un mode entre deux et le mode rapide.

– Est ce que tu synchronise tes lectures/ecritures avec Anais ?

Note que je ne suis pas expert du tout, j’ai simplement lu sur google en recherchant le pourquoi de la lenteur dur debian que je rencontre en ce moment.

Il y a aussi les clusters (FAT32). HD-speed sur PC permet de voir la vitesse que peut supporter de la memoire flash. Par exemple la vitesse en lecture de ma memory stick 16go est passé de 17mo/s a 25 mo/s en passant de 32768 at 65xxx en taille de clusters (au dessus cela ne servait a rien) mais j’ai perdu 20 mo de place environ.
Counia
14 juin 2011 à 23h33 #149455
Le transfert est à la charge du 68000 ?
Gilloo
15 juin 2011 à 9h32 #149456
Counia a écrit :

Le transfert est à la charge du 68000 ?

Oui et non.

La puce qui est dans Subway ou Highway gère des transactions.

On met ce qu’il faut dans une mémoire, on écrit dans un registre et hop ça part (ou ça revient) en trames usb.

Mon problème est que cela fonctionne beaucoup trop lentement.

Cela ne vient pas des tâches, vu que le CPU n’est pas à 100%, ça ne vient pas du HCD non plus vu qu’il n’est pas beaucoup sollicité.

Le device massstorage a une priorité de 15, comme pour les devices scsi.

Tu me diras, c’est mieux qu’un lecteur de disquettes, mais bon j’aimerais bien avoir au moins un débit entre 200 et 300KB/s…
Counia
15 juin 2011 à 18h59 #149457
Déjà mettre en mémoire et écrire un registre, si je me souviens bien sur un autre msg tu disais accéder par octets.

Donc à savoir si un contrôleur décharge le 68000, sinon par expériences en ASM j’ai du code qui plafonne à 50ko/s (c’est par contre en accès synchrone donc jusque 18 cycles sur chaque octet).

Si écrit en C et en plus en respectant le système, ce que tu fais, ça ne m’étonnerait pas de voir un facteur 0,5 à 0,3 sur ce type de transfert.
Gilloo
16 juin 2011 à 12h04 #149458
Counia a écrit :

Déjà mettre en mémoire et écrire un registre, si je me souviens bien sur un autre msg tu disais accéder par octets.

Donc à savoir si un contrôleur décharge le 68000, sinon par expériences en ASM j’ai du code qui plafonne à 50ko/s (c’est par contre en accès synchrone donc jusque 18 cycles sur chaque octet).

Si écrit en C et en plus en respectant le système, ce que tu fais, ça ne m’étonnerait pas de voir un facteur 0,5 à 0,3 sur ce type de transfert.

Oui, mais ce n’est pas cette partie qui rame le plus.

L’accès par octet, concerne l’accès aux registres et la copie dans mémoire de l’uhc124.

Mon problème est que le système est trop lent, comme s’il hésitait à envoyer des données, la tâche d’envoi à l’uhc124 attend, ce qui n’est pas ‘normal’, vu qu’elle devrait être sollicitée toutes les millisecondes.
Mod
Tcheko
16 juin 2011 à 22h53 #149459
Gilloo a écrit :

Counia a écrit :

Déjà mettre en mémoire et écrire un registre, si je me souviens bien sur un autre msg tu disais accéder par octets.

Donc à savoir si un contrôleur décharge le 68000, sinon par expériences en ASM j’ai du code qui plafonne à 50ko/s (c’est par contre en accès synchrone donc jusque 18 cycles sur chaque octet).

Si écrit en C et en plus en respectant le système, ce que tu fais, ça ne m’étonnerait pas de voir un facteur 0,5 à 0,3 sur ce type de transfert.

Oui, mais ce n’est pas cette partie qui rame le plus.

L’accès par octet, concerne l’accès aux registres et la copie dans mémoire de l’uhc124.

Mon problème est que le système est trop lent, comme s’il hésitait à envoyer des données, la tâche d’envoi à l’uhc124 attend, ce qui n’est pas ‘normal’, vu qu’elle devrait être sollicitée toutes les millisecondes.

Sollicitée comment ? C’est une sorte de polling sur timer ?