inventor 0 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба короч че спорить - все что делается - нужно делать с избытком. у меня буферы с запасом минимум на 2 секунды - сбоев пока не было. если сокрашаю время до полусекнды - начинает сбоить Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Я уже посчитал какой размер буфера нужен для устойчивости к такой задержке. Да. У ТС в 10 раз больше. и при этом у него ещё и потери..... Причем, напомню, что ТС начал разговор не задержек и не с потерь, а с дивного утверждения, что ему буфера нужны вообще для того, что-бы РЕЖЕ ПИСАТЬ, типа каких-то "сбоев" меньше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Если такая задержка появляется постоянно, значит это карта с ну очень мееееееееееееееееееееееееееееедленной потоковой скоростью записи. Настолько медленная, что таких не существет :) Просто чуть выше была ссылка на некий документ, который регламентирует макс. длительность операции записи. Прочитали и возрадовались, но вроде бы этот документ не говорит, как часто происходит вот эта аномально долгая операция. Кстати, потоковая скорость записи - она же усредняется по некоторому достаточно большому промежутку времени. И высокая скорость записи не противоречит возможности появления двух подряд операций записи по 250 мс, к примеру. А почему бы и нет? Мы же не знаем, какой именно алгоритм они туда заложили. Выходит, официальный документ не гарантирует спокойной жизни. Приходится полагаться на свидетельства бывалых товарищей и прочие вести с полей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 245 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Кстати, потоковая скорость записи - она же усредняется по некоторому достаточно большому промежутку времени. И высокая скорость записи не противоречит возможности появления двух подряд операций записи по 250 мс, к примеру. А почему бы и нет? Мы же не знаем, какой именно алгоритм они туда заложили. Выходит, официальный документ не гарантирует спокойной жизни. Приходится полагаться на свидетельства бывалых товарищей и прочие вести с полей. Как я понимаю - никаких поисков блоков контроллер карты не производит. Если имеется в виду обычная запись на карту без ФС в непрерывную последовательную цепочку секторов, то длительные задержки (операции стирания) будут появляться среди коротких задержек (операций записи) с периодичностью равной отношению размера блока стирания к размеру блока записи (см. CSD). Все эти счётчики износа - это что-то из более высокоуровневнего ПО (либо из SSD), контроллеры SD-карты, имхо, такое не реализуют. Да, ещё насколько помню, карты умеют делать групповую запись, накапливая некоторое кол-во секторов во внутреннем буфере и потом записывая скопом. Здесь тоже может быть некоторая неравномерность задержек. Но всё равно - потоковая скорость записи при непрерывной линейной записи секторов, должна быть константой на некотором интервале усреднения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Копейкин 0 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Как я понимаю - никаких поисков блоков контроллер карты не производит. Если имеется в виду обычная запись на карту без ФС в непрерывную последовательную цепочку секторов, то длительные задержки (операции стирания) будут появляться среди коротких задержек (операций записи) с периодичностью равной отношению размера блока стирания к размеру блока записи (см. CSD). Все эти счётчики износа - это что-то из более высокоуровневнего ПО (либо из SSD), контроллеры SD-карты, имхо, такое не реализуют. Вроде всё с точностью до наоборот. Современные карты (SDXC) требуют extFAT, потому как "wear leveling" не производят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 245 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Вроде всё с точностью до наоборот.. Приведите соответствующий раздел спецификации SD, где указано что она это делает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Копейкин 0 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Приведите соответствующий раздел спецификации SD, где указано что она это делает. Вот здесь привести документ или цитату не могу. Честно скажу, информация косвенная. Основана на предупреждении с упаковки новой карточки SDXC, где было сказано использовать FAT32 недопустимо, только extFAT. extFAT создана для FLASH носителей требующих выранивание износа и т.п. Тогда как SDSC/SDHC прекрасно обходились FAT16/32. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 8 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Приведите соответствующий раздел спецификации SD, где указано что она это делает. 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
inventor 0 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба я не понимаю к чему спор, мы выпускали сейсмооборудование - предыдущий разработчик делал 2-е резервирование в случае сбоя. т.е. ставил 2 SD карты что там пишут прооизводители - это все реклама практика - критерий истыны: чем реже пищешь тем надежнее Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex11 6 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Мы пишем на карточки разнообразные звук и видео в очень больших объемах. Эффекты наблюдаются при этом самые потрясающие. В том числе и задержки записи (карточка уходит в Busy) до 3 секунд. На девственно чистой карте этих задержек нет. Там есть максимум специфицированные 250 мс или около того. После того, как карта будет записана полностью, часть файлов стерта и записана снова, и так еще пару раз - начинаются большие задержки. Некоторые новые карточки сделаны аккуратно и не имеют этого эффекта. Увеличение размеров буферов помогает, но не сильно. Для борьбы с ним найден единственный разумный способ - при стирании файлов карточке нужно сказать, что место этого файла свободно. (Команда Erase на карту) Свежие версии файловых систем под Linux (fat и ext4) это поддерживают, и в сочетании с правильным указанием параметров при создании разделов и монтировании (выравнивание разделов и элементов файловой системы на 16 МБ) это приводит к отсутствию больших задержек при записи даже при большой скорости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Копейкин 0 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Для борьбы с ним найден единственный разумный способ - при стирании файлов карточке нужно сказать, что место этого файла свободно. (Команда Erase на карту) Свежие версии файловых систем под Linux (fat и ext4) это поддерживают, и в сочетании с правильным указанием параметров при создании разделов и монтировании (выравнивание разделов и элементов файловой системы на 16 МБ) это приводит к отсутствию больших задержек при записи даже при большой скорости. Спасибо, весьма полезная информация. А про выравнивание по 16Мб - это откуда? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Для борьбы с ним найден единственный разумный способ - при стирании файлов карточке нужно сказать, что место этого файла свободно. (Команда Erase на карту) А чего было "искать"? Естественно, что нужно flash стирать перед использованием, тогда не придется делать этого в процессе записи. Естественно, что при использовании классических файловых систем и сооответсвенно "форматировании" это не делается, ибо либо ничего не делается, либо при полном форматировании заполняется тестовым паттерном. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 19 октября, 2015 Опубликовано 19 октября, 2015 (изменено) · Жалоба Да, ещё насколько помню, карты умеют делать групповую запись Групповая запись экономит время, но ещё лучше перед командой групповой записи выдать команду с информацией о размере планируемой записи. Цитату не приведу, у себя пока блочную запись не использую. При записи на карту потока 48 кГц-моно-16 бит заметные задержки (выражающиеся в росте количества буферов, ожидающих записи на карту) иногда происходят, как и у других участников, на время до секунды-полутора, при использовании 96 килобайт буферов потерь данных из-за пропусков практически не происходит (но бывает). Карты на малые объёмы (2/4 GB) меньше страдают задержками. Интерфейс (4 бит или MMC/SPI) не влияет. Изменено 19 октября, 2015 пользователем Genadi Zawidowski Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба ...ещё лучше перед командой групповой записи выдать команду с информацией о размере планируемой записи. Вот сколько не пробовал на SD и SDHC, не попадались мне карты, которые этой информацией пользовались бы. То есть разницы просто не наблюдается, увы :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 19 октября, 2015 Опубликовано 19 октября, 2015 · Жалоба Значит, я не много потерял, не внедряя это в свой код. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
