Ma carte SD semble fonctionner lentement. J'ai une carte SDHC Classe 10 ADATA 16 Go. J'ai vérifié la liste de compatibilité qui répertorie une carte avec des spécifications similaires, et il indique qu'elle "fonctionne". Même des tâches simples comme obtenir une liste de répertoires sur un petit répertoire peuvent prendre quelques secondes la première fois que je le demande. Existe-t-il des outils que je peux utiliser pour vérifier le type de performances que je retire de ma carte SD? De plus, puis-je apporter des modifications à la configuration pour que la carte SD réponde plus rapidement?

J'utilise le Raspberry Pi comme une boîte de départ BitTorrent sans tête , donc tout ce que je rencontre ne fonctionne que sur la ligne de commande. J'utilise la répartition 240/16 pour m'assurer d'avoir la quantité maximale de mémoire disponible.

Mises à jour

Après avoir exécuté quelques tests comme @Krzysztof Adamski recommandé avec "dd", j'ai reçu de bons résultats avec une vitesse de lecture de 20 Mo / s et une vitesse d'écriture d'environ 10 Mo / s. Cependant, il semble toujours avoir des problèmes de vitesse d'E / S. Lors des tests, j'ai exécuté les commandes "dd" en arrière-plan et exécuté en haut pour voir ce qui se passait. J'ai remarqué que le processus "mmcqd" prenait pas mal d'utilisation du processeur, entre 5% et 10%. J'ai regardé autour de moi sur Internet et j'ai trouvé de nombreux cas de personnes rapportant que "mmcqd" utilisait pas mal de CPU. J'ai ensuite exécuté la commande suivante pour tester la lecture et l'écriture en même temps

sudo dd if=/dev/mmcblk0 of=test.dat bs=1M count=1024

Lors de l'exécution de cette commande, j'ai obtenu un débit de seulement 977 ko / s et "mmcqd" a signalé une utilisation du processeur comprise entre 10% et 25% toutes les 5 à 10 secondes, après quoi il ne reviendrait à rien. J'ai donc fait quelques tests supplémentaires. J'ai exécuté les deux commandes suivantes en arrière-plan, puis j'ai regardé ce qui se passait en haut.

sudo dd if=/dev/mmcblk0 of=/dev/null bs=1M count=1024 &
sudo dd if=/dev/zero of=test.dat bs=1M count=1024 &

Dans ce cas, "mmcqd" atteindrait un pic d'environ 35% d'utilisation du processeur, mais le débit était bien meilleur à environ 7,5 Mo / s pour la lecture et environ 5,3 Mo / s pour l'écriture.

Il semble qu'il y ait une sorte de problème en cours où des écritures lourdes provoquent le "mmcqd" pour verrouiller le système. Cela provoque un ralentissement du démon de transmission à presque zéro dès que la vitesse devient trop élevée en attendant la carte SD. Lors de l'exécution du démon de transmission, je vois également que l'utilisation de "mmcqd" est assez élevée.

Test de la vitesse de lecture des cartes:

Il existe deux façons simples de tester la vitesse de lecture (le répertoire de liste n'est qu'une opération de lecture):

• en utilisant la commande dd:

  sudo dd if=/dev/mmcblk0 of=/dev/null bs=8M count=100

  Cela lira 800 Mo de données de votre carte SD et les rejetera dans / dev / null. Si cela prend trop de temps, vous pouvez changer count = 100 en count = 10 pour ne lire que 80 Mo. Une fois la commande terminée, il devrait imprimer un message avec une vitesse de lecture. Vous devriez obtenir au moins quelques Mo / s.

• en utilisant la commande hdparm:

  sudo hdparm -t /dev/mmcblk0

  Cela devrait vous donner un résultat de vitesse similaire à la première commande et devrait également être d'au moins quelques Mo / s.

Test de la vitesse d'écriture des cartes:

Il n'y a pas de moyen facile de tester la vitesse d'écriture, car pour ce faire, vous devriez réellement écrire des données sur la carte. Si vous souhaitez le faire à bas niveau (en omettant le système de fichiers), vous devrez remplacer certaines données sur la carte et vous ne voulez probablement pas le faire. Cela peut être fait si vous avez une partition de swap car elle peut être facilement désactivée (avec swapoff -a), testée avec dd (avec dd if=/dev/zero of=/dev/{yourswappartitionnanehare} bs=8M count=25) puis recréée (avec mkswap /dev/{yourswappartitionnanehare}).

Si vous n'avez pas de partition de swap, vous pouvez tester la vitesse d'écriture du système de fichiers en utilisant également la commande dd:

dd if = / dev / zero of = / home / pi / testfile bs = 8M count = 25

Cela va créer le fichier de 200 Mo /home/pi/testfile. Vous pouvez utiliser tout autre nom de fichier que vous souhaitez.

Remarques:

• Pendant le test de vitesse, assurez-vous qu'aucun autre programme n'est en cours d'exécution sur votre système (comme une application torrent, etc.).
• Après le test, vous pouvez vérifier la sortie de la dmesgcommande pour voir s'il y a des messages sur le sous-système mmc.
• Assurez-vous que le micrologiciel le plus récent est installé. Il existe de temps en temps des correctifs quelle que soit la vitesse de la carte SD.
• Vous pouvez également vérifier certains anciens firmwares car il peut y avoir des régressions. La façon la plus simple de le faire (mais pas la meilleure) est de tester différentes images système qui reposent sur des dates différentes. Le plus difficile est d'utiliser github et de vérifier les versions historiques des fichiers du firmware.

Pour les performances de la carte SD, il importe beaucoup que l'accès soit séquentiel (comme avec dd) ou aléatoire dans de petits blocs. Les cartes SD, en particulier celles de grande classe, semblent être optimisées pour un accès séquentiel, ce qui est bon pour stocker des photos ou des vidéos. Cependant, pour exécuter un système d'exploitation de la carte SD, l'accès aléatoire est plus important, car de nombreux petits fichiers sont lus et écrits. Je suppose que bittorrent génère également des accès quelque peu aléatoires.

Ces deux fils de discussion contiennent de nombreux benchmarks et discussions sur la carte SD. En général, la vitesse d'écriture aléatoire s'est avérée déterminante pour la réactivité de l'exécution d'un système d'exploitation de la carte. Cette vitesse est souvent bien inférieure à la vitesse des écritures séquentielles, qui est la vitesse que les fabricants aiment signaler. La classe de carte SD est basée sur des vitesses séquentielles, et les classes inférieures (4 ou 6) peuvent en fait être plus adaptées à une utilisation de framboise.

L' outil iozone mesure la vitesse de nombreux modèles d'accès différents. J'ai posté de brèves instructions pour compiler l'iozone sur la framboise ici .

Pour la fente intégrée RasPI, il y a une énorme discussion sur le site RasPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

Je n'ai pas eu le temps de lire tout au long des 12 pages de discussion, mais cela semble être un problème avec le signal CLK.

Vous écrivez "bittorrent" et cela déclenche ma supposition / réponse.

Le protocole torrent reçoit des packages dans un ordre aléatoire à partir de semoirs aléatoires.

Une fois que vous commencez à utiliser torrent sur n'importe quel système de fichiers, il devient plutôt fragmenté. Cela nuira aux performances.

D'après ce que je sais sur la SDCARD, son fonctionnement en FAT / FAT32 et c'est encore pire pour gérer la fragmentation.

Alors, trouvez un moyen de défragmenter votre carte SDC, ou copiez tous les fichiers de celle-ci, puis réinstallez le système d'exploitation.

Enfin, écrire un LOT (comme le fera le moteur bittorrent) déchirera votre SDCARD plus rapidement qu'une utilisation normale. Je ne dis pas que c'est mal de le faire, en fait j'avais pensé à me ressembler. Mais - cela pourrait être la raison de votre problème.

Je souhaite qu'il y ait un client torrent qui transfère / déplace automatiquement les fichiers téléchargés vers une toute autre destination une fois le téléchargement + "temps de téléchargement réservé" terminé.

La défragmentation irait alors beaucoup plus vite.