Meu cartão SD parece estar lento. Eu tenho um cartão SDHC Classe 10 ADATA de 16 GB. Eu verifiquei a lista de compatibilidade, que lista um cartão com especificações semelhantes e afirma que está "funcionando". Mesmo tarefas simples, como obter uma lista de diretórios em um diretório pequeno, podem levar alguns segundos na primeira vez que eu solicito. Existem ferramentas que eu possa usar para verificar que tipo de desempenho estou obtendo do meu cartão SD? Além disso, existem alterações na configuração que posso fazer para que o cartão SD responda mais rapidamente?

Estou usando o Raspberry Pi como uma caixa de sementes BitTorrent sem cabeça , então tudo o que estou encontrando está apenas executando na linha de comando. Estou usando a divisão 240/16 para garantir que eu tenha a quantidade máxima de memória disponível.

Atualizações

Depois de executar alguns testes como o @Krzysztof Adamski recomendou com "dd", recebi alguns bons resultados, obtendo uma velocidade de leitura de 20 MB / se uma velocidade de gravação de cerca de 10 MB / s. No entanto, ainda parece estar tendo alguns problemas de velocidade de E / S. Ao testar, executei os comandos "dd" em segundo plano e corri o topo, para ver o que estava acontecendo. Percebi que o processo "mmcqd" estava consumindo bastante o uso do processador, entre 5% e 10%. Olhei em volta na Internet e encontrei muitas instâncias de pessoas relatando que "mmcqd" consome bastante a CPU. Em seguida, executei o seguinte comando para testar a leitura e a gravação ao mesmo tempo

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

Ao executar esse comando, obtive uma taxa de transferência de apenas 977 kB / s, e "mmcqd" relatou o uso do processador entre 10% e 25% a cada 5 a 10 segundos, após o qual ele retornaria a zero. Então, eu fiz mais alguns testes. Executei os dois comandos a seguir em segundo plano e observe o que estava acontecendo no topo.

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

Nesse caso, "mmcqd" atingia um pico de cerca de 35% de uso do processador, mas a taxa de transferência era muito melhor, em torno de 7,5 MB / s para leitura e de 5,3 MB / s para gravação.

Parece que há algum tipo de problema acontecendo aqui, onde gravações pesadas fazem com que o "mmcqd" bloqueie o sistema. Isso faz com que o daemon de transmissão diminua para quase zero assim que a velocidade ficar muito alta enquanto aguarda o cartão SD. Ao executar o daemon de transmissão, também vejo o uso do "mmcqd" bastante alto.

Velocidade de leitura do cartão de teste:

Existem duas maneiras fáceis de testar a velocidade de leitura (o diretório de listagem é apenas uma operação de leitura):

• usando o comando dd:

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

  Isso lerá 800 MB de dados do seu cartão SD e o descartará em / dev / null. Se levar muito tempo, você pode alterar count = 100 para count = 10 para ler apenas 80 MB. Após a conclusão do comando, ele deve imprimir uma mensagem com velocidade de leitura. Você deve obter pelo menos alguns MB / s.

• usando o comando hdparm:

  sudo hdparm -t /dev/mmcblk0

  Isso deve fornecer um resultado de velocidade semelhante ao do primeiro comando e também deve ter pelo menos alguns MB / s.

Velocidade de gravação do cartão de teste:

Não há uma maneira fácil de testar a velocidade de gravação, pois para isso, você precisaria gravar alguns dados no cartão. Se você quiser fazer isso em um nível baixo (omitindo o sistema de arquivos), precisará substituir alguns dados no cartão e provavelmente não deseja fazer isso. Isso pode ser feito se você tiver uma partição swap, pois ela pode ser desativada facilmente (com swapoff -a), testada com dd (with dd if=/dev/zero of=/dev/{yourswappartitionnanehare} bs=8M count=25) e depois recriada (com mkswap /dev/{yourswappartitionnanehare}).

Se você não possui uma partição swap, também pode testar a velocidade de gravação do sistema de arquivos usando o comando dd:

dd se = / dev / zero de = / home / pi / testfile bs = contagem de 8M = 25

Isso criará um arquivo de 200 MB /home/pi/testfile. Você pode usar qualquer outro nome de arquivo que desejar.

Notas:

• Ao testar a velocidade, verifique se nenhum outro programa está sendo executado em seu sistema (como aplicativos de torrent, etc.).
• Após o teste, você pode verificar a saída do dmesgcomando para ver se há alguma mensagem sobre o subsistema mmc.
• Verifique se você possui o firmware mais atualizado instalado. Existem patches, independentemente da velocidade do cartão SD de tempos em tempos.
• Você também pode verificar alguns firmwares mais antigos, pois pode haver algumas regressões. A maneira mais fácil de fazer isso (mas não a melhor) é testar diferentes imagens do sistema criadas em datas diferentes. A maneira mais difícil é usar as versões históricas dos arquivos de firmware do github e checkout.

Para o desempenho do cartão SD, importa muito se o acesso é seqüencial (como no dd) ou aleatório em pequenos blocos. Os cartões SD, especialmente os de alta classe, parecem otimizados para acesso seqüencial, o que é bom para armazenar fotografias ou vídeos. No entanto, para executar um sistema operacional do cartão SD, o acesso aleatório é mais importante, pois muitos arquivos pequenos são lidos e gravados. Eu acho que o bittorrent também gera acessos aleatórios.

Esses dois tópicos de discussão contêm muitos benchmarks e discussões sobre cartões SD. Em geral, a velocidade de gravação aleatória foi decisiva para a capacidade de resposta da execução de um sistema operacional da placa. Essa velocidade geralmente é muito menor que a velocidade das gravações seqüenciais, que é a velocidade que os fabricantes gostam de relatar. A classe do cartão SD é baseada em velocidades sequenciais, e as classes mais baixas (4 ou 6) podem de fato ser mais adequadas para o uso de framboesa.

A ferramenta iozone mede a velocidade de muitos padrões de acesso diferentes. Publiquei breves instruções para compilar o iozone na framboesa aqui .

Para o slot interno do RasPI, há uma grande discussão no site do RasPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

Não tive tempo de ler todas as 12 páginas da discussão, mas parece haver um problema com o sinal CLK.

Você escreve "bittorrent" e isso desencadeia meu palpite / resposta.

O protocolo torrent recebe pacotes em ordem aleatória a partir de propagadores aleatórios.

Quando você começa a usar o torrent em qualquer sistema de arquivos, ele se torna bastante fragmentado. Isso prejudicará o desempenho.

Pelo que sei sobre o SDCARD, está executando o FAT / FAT32 e isso é ainda pior para lidar com a fragmentação.

Portanto, encontre uma maneira de desfragmentar o seu SDCARD ou copie todos os arquivos e reinstale o sistema operacional.

Por fim, escrever um LOT (como o mecanismo bittorrent fará) rasgará seu SDCARD mais rapidamente do que o uso normal. Eu não digo que é errado fazê-lo, fato que eu considerei semelhante a mim mesmo. Mas - esse pode ser o motivo do seu problema.

Eu gostaria que houvesse um cliente de torrent que transferisse / movesse automaticamente os arquivos baixados para outro destino assim que o download + "tempo de upload reservado" fosse concluído.

Então a desfragmentação iria muito mais rápido.