Время записи в SD-card, Почему разное время записи Опции

[*rust*]

Всем привет. Столкнулся с такой проблемой: время записи данных в SD-card разное. Опишу все по порядку:

ядро: AT91SAM3U4E
SD-card: SanDisk 2GB

Данные пишет ARM3 в SD-card, используя библиотеку от Чена. Размер буфера для записи 16кБ.
Перед функцией записи ножку ARMа устанавливаю в "1" после сбразываю в "0", тем самым определяю время записи.
Запуск записи ручной в железе от кнопки (не в дебагере).
С 1 по 31 итерацию время записи 3 мС, 32 итерация длится 40 мС, далее цикл повторяется. Вот такая засада.

Кто сталкивался или знает, что происходит во время 32 итерации записи? Первое, что приходит в голову - это размер буфера в SD-card, примечательно, что 16*32=512, и вполне возможно буфер в SD-card равен 512 кБ. Когда он заполняется, то контроллер, который стоит в SD-card, переписывает его в память. Конечно, сильно притянуто за уши, тем более, что запись во флеш идет постраничная, а размер станиц равный 512кБ я нигде не встречал.

[*rust*]

Проблемой такое поведение не является, и средняя скорость у вас получилась вполне на уровне.

Да как сказать! Мне приходиться писать каждые 100mC 32кБ, с учетом того, есть еще подготовительные операции, то на запись в SD-card отводится 25mC(max), поэтому для меня это проблема.

задержки при записи могут быть достаточно случайными.

Целый вечер вчера тестил, задержка появлялась только после 512кБ, в моем случае на 32 итерации.

У меня достаточно старая SD, 2 года ей где-то, может быть современные ведут себя по другому? И второй вопрос: Программно, существует способ перераспределить время записи?

[VslavX]

Да как сказать! Мне приходиться писать каждые 100mC 32кБ, с учетом того, есть еще подготовительные операции, то на запись в SD-card отводится 25mC(max), поэтому для меня это проблема.

Я недавно занимался тестированием SD-карт, в том числе измерял время записи сектора при массированной последовательной записи блоков различной длины. Поделюсь результатами и своей теорией.
Тест 1 - пишем последовательно в сектор записи по 16 байт, сектор закончился - берем следующий, с номером на единичку большим. Результат - типовое время записи порядка 1 мс (несколько зависит от типа карты и класса), но каждые примерно N записей - провал с некоторым типовым значением. Это значение составляет от 30 мс у самой быстрой новейшей SD 3.0 карты (30Мбайт/сек) до 300 мс у нестарой и заявленной как класс 4 SDHC. Карты 4-5 летней давности уложились в пределы 60-150мс.
Тест 2 - карта предварительно стерта командой SET_LOCK_UNLOCK. Пишем последовательно по целому сектору - типовое время записи сектора осталось то же самое, периодические 'выбросы' тоже есть, но они сократились очень значительно - ну раза в полтора-два больше чем типовое время записи. То есть карта в худшем случае 'думает' всего 2..5мс.
Eще был ряд тестов с привлечением команд стирания, я уже деталей полностью не помню.
Выводы у меня такие - карта, ее внутренний контроллер и его прошивка это черный ящик, но - 99% что основной массив флеш памяти "исповедует" принципы NAND - можно писать страницами (под размер сектора) и стирать только блоками (группами страниц). Отсюда следует основа алгоритма записи - заводится внутри некоторый пул свободных стертых страниц (размер пула равен периоду 'выбросов' времени записи), когда он заканчивается - информация переносится в основное хранилище - или ремаппингом (изменением индексов в базе) или тупо перезаписыванием. Также есть сильное подозрение что если есть возможность записывать сектор сразу на постоянное место (пишущийся сектор в основном массиве "стерт") то пишется на постоянное место.
Итого - если нужный набор секторов стереть (командами стирания) и писать каждый сектор не более одного раза - то такие 'спорадические' увеличения времени записи можно в большинстве случаев купировать. Эксперимент это подтверждает, проверено около 10 карт SD/SDHC разного возраста, объема и производителей.
Выявился еще интересный результат тестов - если в момент 'долгой записи' с карты снять питание (или просто стабилизатор не вытянет броска тока - жрать в этот момент карта начинает ой-ей) или подать команду сброса (так что тайм-ауты корректно все обрабатываем - это карта 'задумалась', а не умерла ), то на некоторых картах приходит пушной зверь - могут разрушиться данные, которые вообще не имели отношения к записываемому сектору - я думаю, что разрушается внутренняя индексная база.

[shishka]

[quote name='VslavX' date='Apr 29 2011, 20:03' post='922688']
Доброого времени суток.
У меня та же проблема с SD картами. Среднюю скорость записи на карту без проблем достигаю 4-6 Мбайт/с. Пишу по кусками по 32 кБайт при помощи CMD25. И мне ужасно мешают жить эти большие задержки по 30-150 мс !!! На проце уже нет свободной ОЗУ, чтобы буфферизировать данные в течение этого времени. Максимум могу делать буфферизацию в течение 25 мс.
Использование команды Pre-erase существенного выигрыша не дает. При предварительном стирании больших кусков памяти при помощи команды CMD38 также не увидел пропадания этих больших задержак при WRITE_MULTIPLY_BLOCK.

Поэтому крайне интересно то, что написал "VslavX"

Цитирую:
"Тест 2 - карта предварительно стерта командой SET_LOCK_UNLOCK. Пишем последовательно по целому сектору - типовое время записи сектора осталось то же самое, периодические 'выбросы' тоже есть, но они сократились очень значительно - ну раза в полтора-два больше чем типовое время записи. То есть карта в худшем случае 'думает' всего 2..5мс. "

Так вот у меня возник вопрос к "VslavX" !!! Что это за команда такая предварительного стирания SET_LOCK_UNLOCK, которой Вы пользовались и которая Вам так облегчила жизнь ????? Можете написать ее номер ???
Вроде как в спецификации на карту оговорены только команды для стирания CMD38 (ERASE) и ACMD23(Pre-erase).

Спасибо

[VslavX]

Так вот у меня возник вопрос к "VslavX" !!! Что это за команда такая предварительного стирания SET_LOCK_UNLOCK, которой Вы пользовались и которая Вам так облегчила жизнь ????? Можете написать ее номер ???

CMD42, с установленным флажком ERASE.
По идее - команда обычного стирания (CMD38) тоже должна помочь, но ее я не пробовал. Возможно у Вас в один и тот же сектор пишется несколько раз после стирания (если там файловая система типа FAT, то такое вполне может быть) - поэтому задержки не устранились.

[shishka]

CMD42, с установленным флажком ERASE.
По идее - команда обычного стирания (CMD38) тоже должна помочь, но ее я не пробовал. Возможно у Вас в один и тот же сектор пишется несколько раз после стирания (если там файловая система типа FAT, то такое вполне может быть) - поэтому задержки не устранились.

Спасибо за ответ, но:
1. Команда CMD42, если я все правильно понимаю, предназначена для блокирования/разблокирования карты. Установка в этой команде флажка ERASE приведет к тому, что в дальнейшем картой будут блокироваться запросы на стирание.
2. На данном этапе я просто тестирую карты и еще не использую файловую систему. Результатом тестирования является гисторграмма распределения длительности записи. Запись в моем тесте идет последовательно и адреса наращиваются тоже последовательно. Так вот, тест показал, что при записи 80000 кусков данных (каждый кусок - это 64 блока по 512 байт) или что тоже самое 2.5 Гбайт на SDHC время записи у, примерно, 5-15 кусков превышает 50 мс. в то время как у оставшихся 7995-7985 кусков оно не превышает и 6 мс!!!
3. Использование команды CMD38 не помогло устранить этой проблемы.

'VslavX' возможно ли как то хотя бы взглянуть на Ваши условия тестирования и полученные результаты ???

Еще что интересно, так это то, что и на зарубежных сайтах не дают четкого ответа откуда возникают это большое "busy time" при мультиблоковой записи и как с ним бороться!!! Тогда как работают, например, видеокамер, которые используют SD карты ??? неужели у них такой большой внутренний буфер (ОЗУ), что его хватает аж на 250 мс видеопотока (250 мс вроде как заявлено в спецификации).

Еще раз спасибо 'VslavX' за ответ

[aaarrr]

Еще что интересно, так это то, что и на зарубежных сайтах не дают четкого ответа откуда возникают это большое "busy time" при мультиблоковой записи и как с ним бороться!!!

Откуда берется не пишут, так как это внутренняя кухня производителя (и у каждого своя), и нет нужды знакомить с ней общественность. На деле все и так более-менее понятно: стирание нового блока, перенос данных из частично пустого для подготовки к стиранию и т.п. издержки организации хранения данных в NAND.
Бороться нельзя никак, природу не обманешь.

Тогда как работают, например, видеокамер, которые используют SD карты ??? неужели у них такой большой внутренний буфер (ОЗУ), что его хватает аж на 250 мс видеопотока (250 мс вроде как заявлено в спецификации).

Конечно, используется достаточно большой буфер: 2-4 мегабайта - это по нынешним временам почти ничего.

[shishka]

Спасибо за ответы.

Для VslavX: По поводу команды CMD42 с установленным флагом ERASE - прошу прощения я не корректно перевел спецификацию.