Можно ли увеличить скорость карты памяти

Оптимизируем SD-карту

Ну что, дорогой читатель, тебя тоже задрали обещания высоких скоростей SD и microSD, однако на деле в твоем уютненьком Linux или Android или вообще на Windows всё, скажем так несколько медленнее, чем заявлено производителем.

Не переживай, и не сокрушайся — скорее всего есть способ тебе помочь.

Немного теории

Несмотря на то, что карта в системе видится, как «диск», данные при записи на флеш пишутся немного по-другому.

Запись организована так называемыми erase-блоками или просто блоками. Блоки имеют определенный размер, в зависимости от размера твоих… флешек.

Для того, чтобы провести запись на диск, приходится стирать не определенный набор секторов, как на диске, а целый блок. Точнее, он не «стирается» физически, а лишь помечается стёртым.

Трансляция из «секторов и дорожек» выполняется «на лету» контроллером и операционной системой.

Короче, всё сложно.

И то, что у тебя SD/microSD «тормозит» — еще не значит что всё плохо. Вполне может быть, что партиции и служебная информация расположены на границах блоков и устройство «напрягается» из-за дополнительных действий. Ну или для записи приходится писать не в один блок, а в два.

Рецепт нулевой-самый простой случай

Если не нужна какая-то специфическая файловая система на SD, постарайся НЕ форматировать её ни в кард-ридере, ни в устройстве. Просто купи, вставь и пользуйся. Кстати никто не запрещает даже обратиться с претензией к продавцу в случае проблем.

Рецепт первый-если ты всё-таки отформатировал карту

Такое, конечно, бывает. И часто. Скорее всего ты нажал кнопочку «очистить карту» или вообще отформатировал её в Windows штатными средствами.

Что произошло

Ты снёс вендоровский FAT (от производителя) и создал новый. Но он создался не совсем там, где был. Таким образом, «стройная система» была нарушена и теперь при записи фоточки любимого кота или себя любимого оно пишется не в один блок, а в два.

Как лечить

На этот случай есть довольно полезная программа для Windows — SDFormatter, которая располагается ни где-то там, а на сайте SD Association, то есть авторы — те самые парни, которые SD придумали и поддерживают.

Внизу есть подпись «FORMAT SIZE ADJUSTMENT OFF». Вот это нас и интересует — нужно эти самые оптимизации включить.

Достаточно пнуть кнопку «Option».

И перевести из режима «OFF» в «ON».

Правда, некоторые «картоводы», особенно полученные нашару из поднебесной или купленные у хачей в ларьке могут отказаться работать с этой программой, так что прекратите пользоваться этим говном и купите себе хотя бы подобие более-менее брендового кардридера — пригодится.

После этой процедуры ситуация должна улучшиться.

Всё, что будет нашкрябано ниже — будет иметь отношение в основном к Linux. Так что если ваш Инстаграмм ждет новых фоточек — пиздуйте его кормить, красноглазикам же и любителям выпуков post-PC эры (Orange Pi, Raspberry Pi) — нижеизложенное будет полезно.

Рецепт второй-оптимизируем для Linux (простой путь)

Покемоны вроде Raspberry Pi, Orange Pi, и прочие дроиды в массе своей грузятся с microSD, поэтому эта тема весьма актуальна.

Внимание, некоторое операции разрушают данные на вашей SD карте, так что сделайте с неё образ на всякий случай или любой другой бэкап, который осилите

Выше уже было про erase-блоки, короче, главная задача тут — расположить нашу партицию с данными ТАК, чтобы она попадала в аккурат в начало блока.

Перед этим нужно произвести некоторые замеры.

Я лично пользовался дешевой карточкой 10го класса от Silicon Power на 32ГБ. После оптимизации выросла скорость (не особо правда), НО резко уменьшилось latency при работе с кучей мелких файлов, что, в свою очередь помогло стабильности системы.

В замерах нам поможет утилита flashbench, известная ещё со времен утопического проекта OLPC.

https://github.com/bradfa/flashbench

Придётся собирать — но там ничего сложного — всё как обычно: configure, make, make install. Впрочем make install даже не нужен — можно запускать с места сборки. Итак…

$ sudo ./flashbench -a /dev/sde —blocksize=1024

align 8589934592 pre 1.59ms on 2.01ms post 1.63ms diff 399µs

align 4294967296 pre 1.58ms on 2.01ms post 1.63ms diff 408µs

align 2147483648 pre 1.59ms on 2.06ms post 1.69ms diff 426µs

align 1073741824 pre 1.64ms on 2.09ms post 1.67ms diff 435µs

align 536870912 pre 1.55ms on 1.97ms post 1.59ms diff 397µs

align 268435456 pre 1.58ms on 1.99ms post 1.6ms diff 396µs

align 134217728 pre 1.63ms on 2.04ms post 1.67ms diff 389µs

align 67108864 pre 1.54ms on 1.95ms post 1.58ms diff 387µs

align 33554432 pre 1.62ms on 2.06ms post 1.64ms diff 428µs

align 16777216 pre 1.72ms on 2.13ms post 1.7ms diff 420µs

align 8388608 pre 1.69ms on 2.11ms post 1.7ms diff 411µs

align 4194304 pre 1.68ms on 2.15ms post 1.76ms diff 432µs

align 2097152 pre 1.65ms on 2.02ms post 1.69ms diff 354µs

align 1048576 pre 1.67ms on 2.04ms post 1.69ms diff 355µs

align 524288 pre 1.72ms on 2.08ms post 1.72ms diff 361µs

align 262144 pre 1.64ms on 2.04ms post 1.68ms diff 378µs

align 131072 pre 1.59ms on 1.96ms post 1.61ms diff 367µs

align 65536 pre 1.6ms on 1.98ms post 1.62ms diff 365µs

align 32768 pre 1.61ms on 2.02ms post 1.64ms diff 397µs

align 16384 pre 1.61ms on 1.99ms post 1.68ms diff 347µs

align 8192 pre 1.69ms on 2.04ms post 1.71ms diff 335µs

align 4096 pre 1.62ms on 2ms post 1.63ms diff 371µs

align 2048 pre 1.65ms on 1.66ms post 1.65ms diff 7.25µs

Утилита пытается работать с блоками разного размера и замеряет скорость работы, точнее время.

В этом потоке сознания нас будут интересовать точки с максимальным «выбросом». Городская легенда (а точнее Gentoo Wiki) гласит, что по ним можно определить такие параметры, как:

• Allocation group
• Erase block
• Multiplane
• Page

Судя по картине, получаем такое:

Allocation group = 1GB Erase block = 4M Multiplane = 32K Page = 4K

На ваших SD цифры могут различаться, но принцип ясен.

Расчет параметров для утилиты fdisk, чтобы партиция попала в нужное место:

4*1024^2/512=8192

Для тех кто хреново учил информатику в школе — напомню, что операция ^ — возведение в степень в BASIC, и не только. И она имеет больший приоритет в математике (это для тех, кто прогулял математику).

512 — размер блока при работе с fdisk. Ниже пример создания партиции:

`Диск /dev/sde: 31.1 Гб, 31104958464 байт

255 головок, 63 секторов/треков, 3781 цилиндров, всего 60751872 секторов

Units = секторы of 1 * 512 = 512 bytes

Размер сектора (логического/физического): 512 байт / 512 байт

I/O size (minimum/optimal): 512 bytes / 512 bytes

Идентификатор диска: 0x000cb560

Устр-во Загр Начало Конец Блоки Id Система

Команда (m для справки): n

Partition type:

p primary (0 primary, 0 extended, 4 free)

e расширенный

Select (default p): p

Номер раздела (1-4, по умолчанию 1): 1

Первый сектор (2048-60751871, по умолчанию 2048): 8192`

Ну дальше просто — делаем нужный размер и вся недолга.

На самом деле, похоже, это ключевой момент для ускорения работы. Следующий рецепт конечно тоже добавляет «скорости», но не так драматично.

But wait! А что, если у нас вначале диска должна быть какая-нибудь загрузочная запись или DOS-партиция, как в случае с AllWinner вообще и Orange Pi в частности ?

В этом случае нам нужно создавать партицию на расстоянии кратном erase-block. Так, если у вас свободное место начинается с 66 мегабайта, то создавать нужно соответственно на 68ом.

Следующий рецепт — тонкая настройка EXT4

Рецепт третий-оптимизируем для Linux (путь истинного красноглазика)

Собственно вернемся к оптимизации — было бы неплохо, если бы и EXT4 была выровненной.

Чтож, формула проста (смотри результаты предыдущего рецепта):

filesystem block = page stride = multi-plane access / page stripe-width = erase block / page

В нашем случае команда:

$ sudo mkfs.ext4 -O ^has_journal -E stride=8,stripe-width=1024 -b 4096 -L linuxroot /dev/sde1

По ощущениям предыдущий рецепт увеличивает скорость работы, а этот уменьшает тот самый latency.

Что ещё подправить в системе

Swap

Очевидно, оптимизацию swap, если он имеется в наличии.

Вот эту хрень:

echo 0 > /proc/sys/vm/swappiness

нужно прописать в rc.local ну или что там у вас. После этого свап будет «в работе», только если исчерпается физический RAM.

Drive scheduler

Это механизм, который отвечает за алгоритм обращения к диску. По умолчанию он скорее всего стоит в режиме cfq, что соответствует обычному HDD. Для microSD или SSD рекомендуется сменить значение на noop или deadline. Я использую noop.

Посмотреть текущий scheduler:

cat /sys/block/{DEVICE-NAME}/queue/scheduler

В нашем случае нужно дать команду (и записать её в тот же rc.local)

echo {SCHEDULER-NAME} > /sys/block/{DEVICE-NAME}/queue/scheduler

Да, не забываем поменять значения в {} на реальные.

TRIM

Еще неплохо бы включить технологию Trim. Для Raspberry Pi она поддержана, а вот на нищебродном Orange Pi — нет. Ну уж этого добра в интернетах — как говна за баней, найдете сами.

Какие ваши доказательства??

Ясное дело, чтобы проверить что всё стало быстрее — надо померить «до» и «после». Измерять можно так:

«Один большой файл»

sync; rm testing; sync; ( dd if=/dev/zero of=testing bs=16k count=10000; sync)

«Много маленьких файлов»

sync; rm -rf testing*; sync; ( for item in `seq 1 1000`; do dd if=/dev/zero of=testing.$item bs=16k count=10; sync; done; )

Запишите результаты до и после изменений. Свои, к сожалению привести не могу — делалось всё в разное время и сложно сказать, что именно было «прорывом».

На этом вроде всё, правда есть ещё пара фишек типа логов в tmpfs, но нужно освежить память — как раз назревает революция с обновлением домашней армовской машины. Как-нибудь в другой раз.

Источник

Медленная работа SD карточек — кто виноват и что делать?

Давно думал написать статью на Хабр, но все как-то не решался. Хотя и кажется, что есть мысли, которые были бы небезинтересны сообществу, но останавливает предположение, что это «кажется» проистекает от завышенной самооценки. Тем не менее попробую. Поскольку я профессионально занимаюсь электроникой, в частности, программированием микроконтроллеров, довольно-таки длительное время (как я подозреваю, дольше, чем живет большАя а может даже и бОльшая часть читателей Хабра), то за это время накопилось изрядное количество интересных случаев. Представляю на суд сообщества рассказ об одном из них.

Итак, в одной разработке мне потребовалось сохранять значительные объемы информации с целью последующей передачи через сеть в обрабатывающий центр. Поскольку полученное устройство предполагало серийное производство, был выбран вариант с применением относительно недорогих компонентов, и, в частности, микроконтроллера как центрального элемента системы. Поскольку в тот момент (середина 2012 года) предложение микроконтроллеров с Ethernet PHY на борту не отличалось разнообразием (да и сейчас положение не намного лучше), был выбран МК фирмы TI семейства Stellaris, конкретно LM3S8962, тем более что отладочная плата для него у меня уже имелась. МК на тот момент относительно новый, активно продвигаемый фирмой TI (это в конце 2013 года она ВНЕЗАПНО перевела всю серию в разряд NRND), и обладающий вполне достаточными для решения данной задачи параметрами. Для хранения информациии был выбран вариант с SD карточкой, в первую очередь из за их доступности и дешевизны, а также потому, что на отладочной плате наличествовало контактное устройство для них, а на поставляемом с платой отладки CD имелись многочисленные примеры, в том числе и для SD карт. Интерфейс к карточке был реализован простейший — SPI, предложенные примеры сходу заработали, принятое решение позволяло обрабатывать полученные данные до написания интерфейса при помощи элементарного переноса карточки из устройства в кард-ридер ПК, так что первоначальная отладка алгоритмов взаимодействия с объектом управления проблем не вызвало, по крайней мере в этой части проекта. Как все понимают, проблемы возникли несколько позже…

Когда алторитмы были отлажены и устройство в целом заработало, начались тестовые прогоны. И тут выясняется, что SD карточка не способна записывать информацию в том темпе, в котором объект управления ее поставляет, причем разница скоростей составляет разы, а с учетом размеров единицы хранения (2.7 мегабайта) создать промежуточный буфер по приемлемой цене не удасться. Переходя к конкретным цифрам, требовалось файл размером 2.7 мегабайта записывать на SD карточку не более, чем за 1.6 секунды, а реально данные записывались 30 секунд, причем карточки были приобретены класса 10, то есть утверждали скорость записи 10 мбайт/сек. Борьба за скорость шла в несколько этапов и противниками оказывались то микроконтроллер, то стандартная библиотека (фирменная от TI между прочим), то, собственно, SD карточки.

Первый этап — исследую тайминги записи и сразу же выясняю, что запись различных участков информации идет разное время, причем время записи одинаковых блоков информации существенно (в разы) отличается. Путем экспериментов с различными размерами блоков записи устанавливаю простую закономерность — чем больше блоки информации для записи, тем меньше время записи, отнесенное к ее размеру. Псокольку модули библиотеки поддерживают FAT и записывают информацию посекторно, а переделывать их смысла не вижу, переформатирую карточку на размер сектора 32 кбайт и получаю время записи 14 секунд — 1 очко SD.

Второй этап — проверяю работы SPI интерфейса и обнаруживаю, что он работает на частоте 12.5 мгц, хотя описание позволяет установить частоту передачи до 25 мгц (половина от тактовой частоты процессора 50 мгц). Выясняется, что подпрограмма установки частоты SPI модуля из библиотеки ограничивает максимально возможную частоту значением 12.5 мгц, причем в документации на интерфейсный модуль микроконтроллера подобное ограничение отсутствует.

i = ROM_SysCtlGet() / 2; if(i > 12500000) { i = 12500000; }

Изменяем код и получаем уменьшение времени записи в 2 раза до 7 секунд — 1 очко TI.

Третий этап — исследую модули обмена с SD карточкой и обнаруживаю весьма непроизводительное расходование времени в низкоуровневых процедурах, а именно: модуль SPI в микроконтроллере имеет в своем составе FIFO буфер на 8 байт, что позволяет ускорить работу с ним. Модуль вывода до передачи очередного байте проверяет флаг «буфер передачи не полон» для ожидания возможности переслать следующий байт, и вроде бы все нормально. Но вслед за передачей байта вызывается модуль приема байта (дело в том, что при передаче в интерфейсе SPI одновременно производится и прием), который должен выбрать из приемного буфера эти ненужные принятые байты. И вот эта процедура опрашивает флаг «буфер приема не пуст», то есть ожидает окончания сериализации последнего байта буфера. То есть ждет, пока не будет полностью передан текущий байт и лишь потом готовит следующий для передачи.

void xmit_spi(BYTE dat) { uint32_t ui32RcvDat; SSIDataPut(SDC_SSI_BASE, dat); /* Write */ SSIDataGet(SDC_SSI_BASE, &ui32RcvDat); /* flush data */ }

Исправляю обнаруженую ошибку (а как это еще назвать ?) и получаю время передачи файла 3 секунды — 1 очко TI.

И вот что получилось в результате оптимизации, не учитывающей особенности задачи.

ic void xmit_spi_my (BYTE const *dst, int length) { int i, *p, *d; d=(int*)(SDC_SSI_BASE+SSI_O_DR); p=(int*)(SDC_SSI_BASE+SSI_O_SR); do { while (!(*p & SSI_SR_TNF)) {} *d=*dst++; } while (—length); while (*p & SSI_SR_RNE) i=*d; }

Четвертый этап — исследую модули более высокого уровня и выясняю что, поскольку передача данных в интерфейс предусмотрена только из памяти, мне приходится проводить двойную работу — сначала читать поток данных из объекта управления и пересылать в оперативную память микроконтроллера (а это, между прочим, 32 килобайта буфера), а потом из памяти в регистры интерфейса SPI. Пишу свой собственный модуль для передачи данных непосредственно из регистра в регистр, и получаю время записи 1.6 секунды. При этом обращение к своему модулю маскирую внутри стандартного вызова, чтобы файловую система понимала, что переданы 32 килобайта — 1 очко TI.

Пятый этап. Поставленная цель уже достигнута, но процесс оптимизации продолжается по инерции. Исследую еще раз сигналы на интерфейсе и обнаруживаю, что на самом деле передается не непрерывная последовательность тактовых импульсов, а 8 бит данных плюс пауза в 2 такта. Ну хорошо, девятый бит нужен для передачи сигнала синхронизации (не путать с тактовым сигналом), причем мне он совершенно не нужен, но десятый то зачем? Эксперименты с различными режимами SPI привели к получению передаваемого сигнала в реальные 8 бит без пропусков и, соответственно, к времени записи 1.3 секунды — 1 очко Stellaris.

Шестой этап. Вроде бы все хорошо, но совершенно неожидано возникает еще 1 проблема — при потоковой записи множества файлов первые 3 укладываются в требуемый интервал и даже с небольшим запасом, а вот четвертый файл показвает время записи намного большее — до 1.8-2.0 секунд и, соответственно, нарушает последовательность. Пробую очевидное решение, предположив что дело в переходах через страницы записи FLASH памяти, и исключаю эти места из обработки. Теперь начинают долго записываться те файлы, которые раньше записывались хорошо. Многочисленные эксперименты приводят к выводу, что поведение FLASH как то связано с ее особенностями внутренней организации. Я полагаю, что внутренний генератор высокого напряжения для записи ( его существование несомненно) не способен удержать требуемый уровень напряжения при длительных операциях и требует определенного времени на восстановление заряда. При этом общая средняя скорость выдерживается, но мне то нужна не средняя скорость, а мгновенная скорость записи каждого файла. Здесь могло бы выручить введение буфера данных для выравнивания нагрузки, но было найдено другое решение — приобретены SD карточки различных фирм и среди них нашлись те, которые давали постоянное время записи в 1.4 секунды без существенных разбросов. Конкретные названия фирм-производителей карточек называть не буду, чтобы не сочли статью рекламной — 1 очко SD.

Итог — задача решена, устройcтва отгружены потребителю и функционируют без сбоев, общий счет по количеству обнаруженных и исправленных проблем: SD карточки — 2, библиотека от TI — 3, особенности микроконтроллера -1. А из всего вышесказанного можно сделать следующий выводы:

1. С особым вниманием следует относится к имеющимся библиотекам стандартных программ с примерами применения. Они, как правило, функционируют и даже иногда без ошибок, но никоим образом НЕ оптимизированы по производительности. Так что смотрим исходные коды (благо они есть) и творчески модифицируем их. Более того, у меня сложилось мнение, что подобные свободно распространяемые бибилиотеки сознательно сделаны неоптимальными, чтобы стимулировать приобретение их платных аналогов.

2. С осторожностью относимся к спецификациям относительно производительности различных устройств, то есть внимательно читаем спецификации, в каких режимах и какие цифры достигнуты, а не просто смотрим 1-2 цифры параметров и решаем, что нас они устроят.

3. Внимательно читаем документацию на модули микроконтроллеров, пытаемся понять их внутреннее устройство, не забываем про осциллограф для изучения реальных процессов на реальной плате.

И в завершение статьи одно маленькое замечание — решил посмотреть, как обстоят дела в реализации аналогичных процедур в новом пакете поддержки микроконтроллеров типа TIVA-C (TivaWare_C_Series-2.0.1.11577). Ну что можно сказать — традиции не нарушены. Абсолютно все те же грабли лежат все в тех же местах, причем добавились еще одни — теперь функциии вызываются не непосредственно из FLASH памяти, а из так называемой ROM библиотеки с использованием двойного индексирования, что быстродействия не прибавляет. Как говорил Михаил Жванецкий «Или мы будет жить хорошо, или мои произведения всегда будут актуальны». Пока что верно второе.

Источник