короч че спорить - все что делается - нужно делать с избытком.
у меня буферы с запасом минимум на 2 секунды - сбоев пока не было.
если сокрашаю время до полусекнды - начинает сбоить

Да.

Причем, напомню, что ТС начал разговор не задержек и не с потерь, а с дивного утверждения, что ему буфера нужны вообще для того, что-бы РЕЖЕ ПИСАТЬ, типа каких-то "сбоев" меньше.

Просто чуть выше была ссылка на некий документ, который регламентирует макс. длительность операции записи. Прочитали и возрадовались, но вроде бы этот документ не говорит, как часто происходит вот эта аномально долгая операция.
Кстати, потоковая скорость записи - она же усредняется по некоторому достаточно большому промежутку времени. И высокая скорость записи не противоречит возможности появления двух подряд операций записи по 250 мс, к примеру. А почему бы и нет? Мы же не знаем, какой именно алгоритм они туда заложили.
Выходит, официальный документ не гарантирует спокойной жизни. Приходится полагаться на свидетельства бывалых товарищей и прочие вести с полей.

Как я понимаю - никаких поисков блоков контроллер карты не производит. Если имеется в виду обычная запись на карту без ФС в непрерывную последовательную цепочку секторов,
то длительные задержки (операции стирания) будут появляться среди коротких задержек (операций записи) с периодичностью равной отношению размера блока стирания к размеру блока записи (см. CSD).
Все эти счётчики износа - это что-то из более высокоуровневнего ПО (либо из SSD), контроллеры SD-карты, имхо, такое не реализуют.

Да, ещё насколько помню, карты умеют делать групповую запись, накапливая некоторое кол-во секторов во внутреннем буфере и потом записывая скопом. Здесь тоже может быть некоторая неравномерность задержек.
Но всё равно - потоковая скорость записи при непрерывной линейной записи секторов, должна быть константой на некотором интервале усреднения.

Вроде всё с точностью до наоборот.
Современные карты (SDXC) требуют extFAT, потому как "wear leveling" не производят.

Приведите соответствующий раздел спецификации SD, где указано что она это делает.

Вот здесь привести документ или цитату не могу.
Честно скажу, информация косвенная.
Основана на предупреждении с упаковки новой карточки SDXC, где было сказано
использовать FAT32 недопустимо, только extFAT.
extFAT создана для FLASH носителей требующих выранивание износа и т.п.
Тогда как SDSC/SDHC прекрасно обходились FAT16/32.

The controller in Delkin’s Industrial SLC microSD cards implements an
efficient bad block management algorithm to detect the factory-produced bad blocks and manage
any bad blocks that appear with use.

http://delkinoem.com/oem-engineering-specs...icroSD-Spec.pdf

я не понимаю к чему спор, мы выпускали сейсмооборудование -
предыдущий разработчик делал 2-е резервирование
в случае сбоя. т.е. ставил 2 SD карты
что там пишут прооизводители - это все реклама
практика - критерий истыны: чем реже пищешь тем надежнее

Мы пишем на карточки разнообразные звук и видео в очень больших объемах. Эффекты наблюдаются при этом самые потрясающие. В том числе и задержки записи (карточка уходит в Busy) до 3 секунд. На девственно чистой карте этих задержек нет. Там есть максимум специфицированные 250 мс или около того. После того, как карта будет записана полностью, часть файлов стерта и записана снова, и так еще пару раз - начинаются большие задержки. Некоторые новые карточки сделаны аккуратно и не имеют этого эффекта. Увеличение размеров буферов помогает, но не сильно. Для борьбы с ним найден единственный разумный способ - при стирании файлов карточке нужно сказать, что место этого файла свободно. (Команда Erase на карту) Свежие версии файловых систем под Linux (fat и ext4) это поддерживают, и в сочетании с правильным указанием параметров при создании разделов и монтировании (выравнивание разделов и элементов файловой системы на 16 МБ) это приводит к отсутствию больших задержек при записи даже при большой скорости.

Спасибо, весьма полезная информация.
А про выравнивание по 16Мб - это откуда?

А чего было "искать"? Естественно, что нужно flash стирать перед использованием, тогда не придется делать этого в процессе записи. Естественно, что при использовании классических файловых систем и сооответсвенно "форматировании" это не делается, ибо либо ничего не делается, либо при полном форматировании заполняется тестовым паттерном.

Групповая запись экономит время, но ещё лучше перед командой групповой записи выдать команду с информацией о размере планируемой записи. Цитату не приведу, у себя пока блочную запись не использую. При записи на карту потока 48 кГц-моно-16 бит заметные задержки (выражающиеся в росте количества буферов, ожидающих записи на карту) иногда происходят, как и у других участников, на время до секунды-полутора, при использовании 96 килобайт буферов потерь данных из-за пропусков практически не происходит (но бывает). Карты на малые объёмы (2/4 GB) меньше страдают задержками.
Интерфейс (4 бит или MMC/SPI) не влияет.



Сообщение отредактировал Genadi Zawidowski - Oct 19 2015, 21:29

Вот сколько не пробовал на SD и SDHC, не попадались мне карты, которые этой информацией пользовались бы.
То есть разницы просто не наблюдается, увы

Значит, я не много потерял, не внедряя это в свой код.