[jcxz 184]

Представьте, как карта может записать 32К, которые пересекают границу соседних 4М блоков?

И что из того? Эти самые большие блоки она будет стирать или нет?

ТСу важна не средняя скорость записи, а максимально возможные задержки. Именно от них зависит требуемая глубина буферизации, которая у него отсутствует почему-то.

[makc 192]

И что из того? Эти самые большие блоки она будет стирать или нет?

 

Понятно, что стирать она будет, т.к. для записи это делать придется. А вот когда она это будет делать и сколько она будет после стирания перемещать данных и есть вопрос, определяющий задержки и среднюю скорость записи. Я имею в виду то, что для запись новых данных идёт в рамках открытого блока в новый ("стёртый" или "свободный") блок. При этом изменение места записи приводит к закрытию текущего блока и результирующему переносу неперезаписанных данных из оригинального блока в частично записанный новый. В идеале, если новый блок был полностью перезаписан, то переносить ничего не нужно, а достаточно закрыть блок, стереть его старую копию и работать дальше. При этом, теоретически, операцию стирания можно было бы запустить в параллель в остальными процессами.

 

ТСу важна не средняя скорость записи, а максимально возможные задержки. Именно от них зависит требуемая глубина буферизации, которая у него отсутствует почему-то.

 

Я думаю, что средняя скорость записи тоже важна. К тому же величина задержек, на мой взгляд, так же связана с организацией хранения данных на карте. По крайней мере об этом говорит мой практический опыт.

 

[jcxz 184]

При этом, теоретически, операцию стирания можно было бы запустить в параллель в остальными процессами.

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

(Если Вы таковую знаете - назовите её).

И вообще - где все эти операции перемещения/перераспределения/...? В SD-карте? Вы уверены? Где блоки разного размера и выравнивание износа? Вы не путаете с какими-то другими типами flash-памяти?

Из спецификации SD:

For block-oriented commands, the following definition is used: 
•       Block—The unit that is related to the block-oriented read and write commands. Its size is the number 
of bytes that are transferred when one block command is sent by the host. The size of a block is either 
programmable or fixed. The information about allowed block sizes and the programmability is stored 
in the CSD. 
The granularity of the erasable units is in general not the same as for the block-oriented commands: 
•       Sector—The unit that is related to the erase commands. Its size is the number of blocks that are erased 
in one portion. The size of a sector is fixed for each device. The information about the sector size (in 
blocks) is stored in the CSD.

Вот и всё. Пишет - блоками, стирает - секторами. Сектор состоит из SECTOR_SIZE блоков. Эти значения заданы константами в CSD и для каждого там только одна константа.

Правда есть поле ERASE_BLK_EN - разрешение стирания блоков. Но это также относится ко всем блокам карты, а не к некоторым, расположенным в начале или конце. Т.е. - сектора и блоки по всему объёму SD-карты одинаковы по времени стирания/записи (при одинаковом износе конечно).

И в спецификации SD я не видел нигде упоминания про какие-то операции по выравниванию износа, выполняемые картой. Какие блоки сказали ей писать, она те и пишет, сама ничего не перемещая.

Вот возможность наличия RAM-буфера внутри SD-карты для буферизации потока записываемых данных спецификация не исключает. Да и протокол обмена с картой имхо не мешает сделать буферизацию потока записываемых блоков в карте стирая и записывая данные по мере их приёма и накапливания в буфере. Но спецификация и не обещает наличие буфера внутри.

 

PS: Да полезная вещь для ТС - возможно ему нужно выбирать карты с ERASE_BLK_EN=1 и стирать блоками. Блок меньше и его стирание должно быть быстрее.

[makc 192]

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

 

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?

Вот статья 2003 года, отчасти подтверждающая мои слова про наличие механизмов выравнивания износа.

[jcxz 184]

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

Да я допускаю что внутри там может быть более сложная организация. Я и писал что возможно там есть буферизация потока записываемых блоков (о чём косвенно свидетельствует алгоритм работы команды многоблочной записи).

Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.

Но только - зачем ему оно надо? Тратить ресурсы на более сложную разработку, тратить лишние вентили на весь этот механизм, может их лучше потратить на доп. ячейки флешь и сделать бОльшую ёмкость?

Ведь главная цель изготовителя - извлечение прибыли и уменьшение издержек. И если оно не требуется спецификацией, то может кто так и будет делать, то такие карты ТСу ещё найти надо.

 

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?

И что? Число циклов перезаписи не говорит, что по достижении этого значения, блок сразу откажет. Это минимальное число стираний которое блок должен выдержать, а в реале может в разы больше выдержать.

Вот я сейчас разбираюсь с регенерацией SDRAM. Так вот провожу испытания - выключаю регенерацию и измеряю сколько данные продержатся без регенерации. По даташиту регенерацию надо выполнять не реже чем раз в 64мсек, т.е. хранение данных без регенерации более 64мсек не гарантировано.

А в реале (заполняю всю SDRAM 32МБ псевдослучайными значениями и через заданное время проверяю всю целиком) разрушение данных наблюдаю только после отключения регенерации на 3-4 сек и более.

Если на 1 сек отключить регенерацию, то данные 100%-но сохраняются.

[[email protected] 0]

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:

http://electronix.ru/forum/index.php?showt...32833&st=31

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

[Alex11 3]

Чтобы минимизировать задержки при длительной записи на SD нужно при стирании файлов давать команды trim или erase на карту, в зависимости от того, что она поддерживает. В свежем linux при монтировании можно указать ключом (discard) необходимость использования этих команд. При этом существенно улучшается ситуация с длинными паузами, т.к. карточке не приходится переписывать внутри многократно данные, которые на самом деле уже не используются файловой системой. Это не отменяет необходимости использовать большие блоки для записи (лучше по 16 МБ).

[MiklPolikov 0]

Показалась интересной мысль про то что карта тратит время на стирание.

Стёр всю карту CMD32 CMD33 CMD38

Задержки не уменьшились

 

Припоминаю, где то ещё была опция автоматического стирания блока перед записью, или что-то вроде того. Подскажите, где это было ?

[aaarrr 63]

Стёр всю карту CMD32 CMD33 CMD38

А время стирания не измерили, было ли оно вообще?

 

Припоминаю, где то ещё была опция автоматического стирания блока перед записью, или что-то вроде того. Подскажите, где это было ?

ACMD23. Мне не встречались карты, на которых эта команда давала бы реальное ускорение записи.

[jorikdima 0]

многократно тема поднималась тут. Сам сталкивался, имел задержки до 400мс. Буфер конечно решает, но размер впрямую зависит от потока.

[MiklPolikov 0]

А время стирания не измерили, было ли оно вообще?

 

Около 2с для карты 8Гб

 

[jcxz 184]

А время стирания не измерили, было ли оно вообще?

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

 

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

Ещё раз: Где в спецификации SD говорится, что карта что-то там внутри себя переписывает????

Дайте ссылку.

[makc 192]

Ещё раз: Где в спецификации SD говорится, что карта что-то там внутри себя переписывает????

Дайте ссылку.

 

Дайте, пожалуйста, ссылку, какую спецификацию Вы имеете в виду. Дело в том, что ранее Вы приводили ссылки на текст Part 1 (Physical Layer Specification) и на мой взгляд совершенно очевидно, что внутренняя структура хранения данных карты лежит за пределами того, что описывается этой спецификацией. Поэтому я и хочу понять, в какой части спецификации SD, по Вашему мнению, задаются методы, алгоритмы и структуры внутренних данных карты.

 

 

Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.

Но только - зачем ему оно надо? Тратить ресурсы на более сложную разработку, тратить лишние вентили на весь этот механизм, может их лучше потратить на доп. ячейки флешь и сделать бОльшую ёмкость?

Ведь главная цель изготовителя - извлечение прибыли и уменьшение издержек. И если оно не требуется спецификацией, то может кто так и будет делать, то такие карты ТСу ещё найти надо.

 

Вот именно ради извлечения прибыли и стали усложняться механизмы обеспечения надёжности, в частности методы выравнивания износа ячеек памяти. Т.к. с удешевлением памяти неизбежно стала падать её надёжность, выражаемая в гарантированном числе циклов перезаписи.

 

И что? Число циклов перезаписи не говорит, что по достижении этого значения, блок сразу откажет. Это минимальное число стираний которое блок должен выдержать, а в реале может в разы больше выдержать.

 

Вы пробовали или только предполагаете работу блоков памяти после заданного числа циклов стирания?

Второй вопрос: поставьте себя на место производителя карт памяти или флешек - исходя из чего Вы будете назначать гарантийный срок?

 

Вот я сейчас разбираюсь с регенерацией SDRAM. Так вот провожу испытания - выключаю регенерацию и измеряю сколько данные продержатся без регенерации. По даташиту регенерацию надо выполнять не реже чем раз в 64мсек, т.е. хранение данных без регенерации более 64мсек не гарантировано.

А в реале (заполняю всю SDRAM 32МБ псевдослучайными значениями и через заданное время проверяю всю целиком) разрушение данных наблюдаю только после отключения регенерации на 3-4 сек и более.

Если на 1 сек отключить регенерацию, то данные 100%-но сохраняются.

 

Прекрасный эксперимент, который говорит лишь о том, что в отдельной точке мирового пространства при имеющихся в ней физических условиях Вы наблюдали описанную картину. В то время как память имеет весьма широкий диапазон рабочих температур и напряжений питания, что означает необходимость обеспечения надёжной работы во всем диапазоне заданных производителем условий. Попробуйте на досуге, проведите эксперимент во всех возможных условиях, а не только на теплом столе. И если при всех этих условиях после отключённой на 1 сек регенерации данных так же 100%-но будут сохраняться, готов буду дальше обсуждать этот вопрос в таком контексте. В противном я не могу считать Ваши слова сколь-либо ценным аргументом.

 

 

[MiklPolikov 0]

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:

http://electronix.ru/forum/index.php?showt...32833&st=31

 

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

[makc 192]

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

 

FATFS написан неэффективно и чуть что лезет писать в FAT, причём пишет совсем понемногу. Поэтому для оптимизации доступа имеет смысл сделать промежуточный слой доступа к носителю (типа кэша), который будет накапливать эти модификации и потом редко записывать единым блоком. И, кстати, стоит обратить внимание на то, как FatFS сконфигурирован. Надеюсь у Вас _FS_TINY == 0 ?