Моя SD-карта, здається, працює повільно. У мене є карта ADATA 16 Гб SDHC класу 10. Я перевірив список сумісності, в якому перерахована карта зі схожими специфікаціями, і в ній зазначено, що вона "працює". Навіть такі прості завдання, як отримання списку каталогів у невеликому каталозі, можуть зайняти кілька секунд, коли я запрошую його. Чи є інструменти, які я можу використовувати, щоб перевірити, яку ефективність я отримую зі своєї SD-карти? Крім того, чи можна змінити конфігурацію, щоб швидше реагувати на SD-карту?

Я використовую Raspberry Pi як безголовий насіннєвий ящик BitTorrent , тому всі речі, в які я запускаюсь, просто працюють у командному рядку. Я використовую розрив 240/16, щоб забезпечити наявність максимального обсягу пам'яті.

Оновлення

Після виконання деяких тестів, як рекомендував @Krzysztof Adamski з "dd", я отримав кілька хороших результатів, отримавши швидкість читання 20 Мб / с і швидкість запису близько 10 Мб / с. Однак, як видається, виникають деякі проблеми зі швидкістю вводу / виводу. Під час тестування я запускав команди "dd" на задньому плані та біг зверху, щоб побачити, що відбувається. Я помітив, що процес "mmcqd" займає досить багато використання процесора, від 5% до 10%. Я оглянувся в Інтернеті і виявив багато випадків, коли люди повідомляють, що "mmcqd" використовує досить багато процесора. Потім я запустив наступну команду, щоб перевірити читання і запис одночасно

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

Під час виконання цієї команди я отримав пропускну здатність лише 977 кБ / с, і "mmcqd" повідомив про використання процесора між 10% і 25% кожні 5 - 10 секунд, після чого він повернеться ні до чого. Отже, я зробив ще кілька тестувань. Я виконував наступні дві команди на задньому плані, а потім спостерігав, що відбувається вгорі.

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

У цьому випадку "mmcqd" досягав би максимального використання 35% процесора, але пропускна здатність була набагато кращою, приблизно 7,5 Мб / с для читання і близько 5,3 Мб / с для запису.

Здається, тут виникає якась проблема, коли важкі записи викликають блокування системи "mmcqd". Це змушує демона передачі сповільнюватися майже до нуля, як тільки швидкість стає занадто високою, коли він чекає на SD-карту. Під час роботи передач-демон я також бачу, що використання "mmcqd" стає досить високим.

Швидкість зчитування картки тестування:

Існує два простих способи перевірити швидкість читання (каталог лістингу - це лише операція читання):

• за допомогою команди dd:

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

  Це дозволить прочитати 800 Мб даних з вашої SD-карти та відкинути це в / dev / null. Якщо це займає багато часу, ви можете змінити count = 100 на count = 10, щоб прочитати лише 80MB. Після завершення команди вона повинна надрукувати повідомлення зі швидкістю читання. Ви повинні отримати принаймні пару Мб / с.

• за допомогою команди hdparm:

  sudo hdparm -t /dev/mmcblk0

  Це повинно дати вам схожий результат швидкості, як і перша команда, а також має становити принаймні пару МБ / с.

Швидкість запису картки:

Немає простого способу тестування швидкості запису, оскільки для цього вам доведеться фактично записати деякі дані на карту. Якщо ви хочете зробити це на низькому рівні (опускаючи файлову систему), вам доведеться переотримати деякі дані на картці, і ви, ймовірно, не хочете цього робити. Це можна зробити, якщо у вас є розділ swap, оскільки його можна легко деактивувати (з swapoff -a), протестувати з dd (with dd if=/dev/zero of=/dev/{yourswappartitionnanehare} bs=8M count=25) і потім відтворити (with mkswap /dev/{yourswappartitionnanehare}).

Якщо у вас немає розділу swap, ви можете перевірити швидкість запису файлової системи також за допомогою команди dd:

dd, якщо = / dev / zero of = / home / pi / testfile bs = 8M count = 25

Це створить файл 200MB в /home/pi/testfile. Ви можете використовувати будь-яке інше ім’я файлу.

Примітки:

• Під час тестування швидкості, переконайтеся, що у вашій системі не запускаються інші програми (наприклад, торрент-програма тощо).
• Після тестування ви можете перевірити вихід dmesgкоманди, щоб побачити, чи є повідомлення про підсистему mmc.
• Переконайтеся, що у вас встановлена ​​найновіша версія прошивки. Існують патчі, незалежно від швидкості SD-карти час від часу.
• Ви також можете перевірити деякі старі прошивки, оскільки можливі регресії. Найпростіший спосіб зробити це (але не найкраще) - протестувати різні системні зображення, які створюються в різні дати. Важчий спосіб - використовувати github і оформити історичні версії файлів прошивки.

Для продуктивності SD-карти важливо, незалежно від того, чи є доступ послідовним (як у dd) або випадковим доступом у невеликих блоках. SD карти, особливо високого класу, схоже, оптимізовані для послідовного доступу, що добре для зберігання фотографій чи відео. Однак для роботи ОС на SD-картці випадковий доступ важливіший, оскільки читається і записується багато невеликих файлів. Я б здогадався, що bittorrent також генерує дещо випадкові звернення.

Ці два теми обговорення містять безліч орієнтирів та дискусійних карт SD. Загалом, швидкість випадкового запису виявилася визначальною для чуйності роботи ОС на картці. Ця швидкість часто набагато нижча, ніж швидкість послідовного запису, яка є швидкістю, яку виробники люблять повідомляти. Клас SD-карти базується на послідовних швидкостях, і нижчі класи (4 або 6) насправді можуть бути більш придатними для використання в малині.

Інструмент іозону вимірює швидкість багатьох різних моделей доступу. Я відправив інструкції зі складання коротких IOzone на малину тут .

Про бортовий слот RasPI існує величезна дискусія на сайті RasPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

Не встигли прочитати всі 12 сторінок обговорення, але, здається, це проблема із сигналом CLK.

Ви пишете "bittorrent", і це викликає мою здогадку / відповідь.

Торрент-протокол отримує пакети у випадковому порядку від випадкових сівалок.

Щойно ви починаєте використовувати торрент у будь-якій файловій системі, він стає досить фрагментарним. Це зашкодить виконанню великого часу.

З того, що я знаю про SDCARD, його FAT / FAT32 та ще гірше для обробки фрагментації.

Тож знайдіть спосіб дефрагментації SDCARD або скопіюйте з нього всі файли та повторно встановіть ОС.

Нарешті, написання ЛОТу (як це станеться в режимі bittorrent) зірве ваш SDCARD швидше, ніж звичайне використання. Я не кажу, що це неправильно, це я вважав подібним. Але - це може бути причиною вашої проблеми.

Я хотів би, щоб був торент-клієнт, який автоматично переніс / перемістить завантажені файли до цілого іншого місця призначення, як тільки завершиться завантаження + "зарезервований час завантаження".

Тоді дефрагментація пішла б набагато швидше.