День добрый!
если у кого есть опыт, был бы весьма признателен за ответ на следующий вопрос:
утрированно задача следующая -
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
из первого файла 16 кило, из второго 16 кило итд, и так по кругу, складывая это в буфера в озу.
Так вот в разрезе этой задачи интересуют оценки сверху по времени на следующие операции -
1 - переключение чтения с одного файла на другой (получается переключение с одногосеткора на другой, для нанд флэши эти данные есть, но ведь в карте свой контроллер)
2 - время открытия файла, если это FAT
А если файлов не 1000 а 64 допустим?
чтение будет требоваться, примерно 3-6 мегабайт в секунду...
Сорри за расплывчатое объяснение, необходимо понять стоит ли покупть отладочную плату для опытов в принципе - или затея изначально не решаемая.
По АРМ-ам - смотрю в сторону атмелов SAM9X или NXP (по перефирии подкупает новая серия 3130, но отладочные платы видимо будут ещё не скоро...), у них есть SDIO - тюе можно получить (видимо) вменяемую скорость...
Спасибо!
Полная версия этой страницы: ARM9 и SD карта - скорость доступа
Цитата(Serg_D @ Oct 28 2008, 16:22) 
1 - переключение чтения с одного файла на другой (получается переключение с одногосеткора на другой, для нанд флэши эти данные есть, но ведь в карте свой контроллер)
Смотри разницу между CMD_17 (READ_SINGLE_BLOCK) и CMD_18 (READ_MULTIPLE_BLOCK).
Грубо говоря, задержка на выдачу и респонс одной команды.
Цитата(Serg_D @ Oct 28 2008, 16:22)
2 - время открытия файла, если это FAT
А если файлов не 1000 а 64 допустим?
А если файлов не 1000 а 64 допустим?
Читаеш один раз фат во внутреннее озу и работай с ним.
Цитата(Serg_D @ Oct 28 2008, 16:22)
чтение будет требоваться, примерно 3-6 мегабайт в секунду...
Я на SAM7S делал 1.5, а там SDIO нет. ПЛИСина помогала. Так что думаю, вполне возможно.
А если SDHC так уж точно.
Цитата(Serg_D @ Oct 28 2008, 15:22)
утрированно задача следующая -
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
1000 файлов - лучше всего объеденить в один файл с шапкой-таблицей со смещением относительно начала файла, писать на отформатированную флешку (читать без FAT), тогда и скорость будет выше и можно будет в корень положить (так как в FAT макс. количество файлов в корне не более 128 включая метку диска).
спасибо за ответы.
на самом деле больше всего интересует время "перепозиционирования" с одного файла на другой, или с одного положения в файле на другое, т.е не потоковое чтение а рандомное так сказать.
т.е это десякти микросекунд, сотни, или милисекундны...
на самом деле больше всего интересует время "перепозиционирования" с одного файла на другой, или с одного положения в файле на другое, т.е не потоковое чтение а рандомное так сказать.
т.е это десякти микросекунд, сотни, или милисекундны...
Думается мне, что держать "открытыми" 1000 файлов уже дело хорошее. Дла начала можно было бы это дело испытать на PC. USB-ный reader не так уж медленно работает.
Можно одновременно не открывать все файлы. А открывать асинхронно только ближайшую десятку в отделных задачах.
Конечно, не принято держать открытыми много файлов поскольку в файловых системах не оптимизируется поиск по списку открытых файлов и еще потенциально такая операция может оставить дико фрагментированный heap не говоря уж о ресурсах на такое действие.
Для SDIO думаю выложу результаты, а вот для SPI 20 МГц на ARM 100 МГц мной был для FAT получен результат: открытие файла - 2.5...10 мс, закрытие файла - 8...10 мс. Очень предварительно, статистика буквально с нескольких попыток.
Самое большое влияние на скорость оказывает состояние самой SD карты. Собственно оно не предсказуемо. Чем больше было записано и стерто файлов на SD тем тормознее она становится.
Конечно, не принято держать открытыми много файлов поскольку в файловых системах не оптимизируется поиск по списку открытых файлов и еще потенциально такая операция может оставить дико фрагментированный heap не говоря уж о ресурсах на такое действие.
Для SDIO думаю выложу результаты, а вот для SPI 20 МГц на ARM 100 МГц мной был для FAT получен результат: открытие файла - 2.5...10 мс, закрытие файла - 8...10 мс. Очень предварительно, статистика буквально с нескольких попыток.
Самое большое влияние на скорость оказывает состояние самой SD карты. Собственно оно не предсказуемо. Чем больше было записано и стерто файлов на SD тем тормознее она становится.
Цитата(sergeeff @ Oct 28 2008, 21:29)
Думается мне, что держать "открытыми" 1000 файлов уже дело хорошее. Дла начала можно было бы это дело испытать на PC. USB-ный reader не так уж медленно работает.
Цитата(AlexandrY @ Oct 28 2008, 22:08)
Для SDIO думаю выложу результаты, а вот для SPI 20 МГц на ARM 100 МГц мной был для FAT получен результат: открытие файла - 2.5...10 мс, закрытие файла - 8...10 мс.
Совершенно абстрактные цифири, ибо зависят от реализации работы с FAT. Ну и 10ms для закрытия файла открытого на чтение вообще совершенно дикое число для просто "забыть" про файл.
Цитата(zltigo @ Oct 28 2008, 23:19)
Совершенно абстрактные цифири, ибо зависят от реализации работы с FAT. Ну и 10ms для закрытия файла открытого на чтение вообще совершенно дикое число для просто "забыть" про файл.
Ну может товарищ дескриптор файлов динамически в куче создает, а по закрытию - освобождает. Можно и такие цифры заполучить.
Я уже понял что для оптимизации лучше все данные "слить" в один файл исключив фрагментацию итп, и после этого просто переходить на нужнный сектор для чтения нужных данных, это вполне реализуемо. Единственное что мне нужно - чтоб карта читалась под Win на обычном компе, пусть даже она содержит один большой файл =)
Т.е задача сводится к чтению со случайного места в одном, ну или в нескольких файлах.
При этом мне необходимо только чтение, никакой записи.
Если для карт существуют какие-то градации "качества" (я читал про подобные для SDHC), то тоже могу вполне ограничиться использованием только карт "класса АБС и выше".
Всё что мне нужно, быть у веренным что в данных условиях я могу заложиться на время доступа меньше допустим к примеру 10-ти милисекунд, т.е какого-то ограниченного времени, ну и конечно хотелось бы минимального =)
Т.е задача сводится к чтению со случайного места в одном, ну или в нескольких файлах.
При этом мне необходимо только чтение, никакой записи.
Если для карт существуют какие-то градации "качества" (я читал про подобные для SDHC), то тоже могу вполне ограничиться использованием только карт "класса АБС и выше".
Всё что мне нужно, быть у веренным что в данных условиях я могу заложиться на время доступа меньше допустим к примеру 10-ти милисекунд, т.е какого-то ограниченного времени, ну и конечно хотелось бы минимального =)
Скорость доступа к отдельному произвольному сектору карты на 90% зависит от самой карты. При чтении по одному сектору на "правильном" контроллере (который держит тактовую при обмене в пределах 20-25МГц или даже выше для новых карт) основное время - это ожидание готовности карты после посылки ей команды чтения - за это время контроллер карты найдет внутри сектор, выполнит все необходимые внутренние процедуры ремаппинга и коррекции и будет готов отдавать данные по шине контроллеру.
Так вот, это характерное время составляет порядка 1 миллисекунды. Время самого обмена данными сектора - пренебрежимо мало - 512*8 - 4Кбита - 1К циклов на 4-х битной шине - при 25МГц - всего 40мкс. И если читать по одному сектору "вразброс" то получим скорость - порядка 512*1K (1000 циклов по 1мс) - всего 512Килобайт. Эта скорость может быть чуть выше или чуть ниже - в-основном зависит от карты, но на двух десятках проверенных мной карт, включая самые новые SDHC, не поднималась выше 2Мбайт/сек.
Другое дело, что контроллер карт очень сильно оптимизирован на операции с последовательными секторами -тут уже скорость может существенно быть выше - при чтении по 32 сектора мне удавалось на SD подняться и до 8Мбайт/сек. Если используется файловая система - то, скорее всего, читать можно будет именно кластерами по нескольку секторов за одну операцию, и оптимизацией контроллера под групповые операции вполне можно воспользоваться.
P.S. Вот результаты испытаний на S2410 - аппаратный контроллер MMC/SD - частота тактирования шины MMC/SD 16.625МГц (и дело было в 2006 - карты были не особо новые)
MMC SD
Теоретическая пропускная способность (max): 2.08MBps 8.31 MBps
Результаты практических испытаний
Чтение по одному 512-байтному блоку: 0.83 MBps 1.79 MBps
Чтение группами по 8 512-байтных блоков: 1.40 MBps 5.41 MBps
Чтение группами по 12 512-байтных блоков: 1.54 MBps 5.70 MBps
Чтение группами по 16 512-байтных блоков: 1.60 MBps 5.81 MBps
Чтение группами по 120 512-байтных блоков: 1.87 MBps 7.78 MBps
Запись по одному 512-байтному блоку: 0.19 MBps 0.42 MBps
Запись группами по 12 512-байтных блоков: 0.40 MBps 1.69 MBps
Так вот, это характерное время составляет порядка 1 миллисекунды. Время самого обмена данными сектора - пренебрежимо мало - 512*8 - 4Кбита - 1К циклов на 4-х битной шине - при 25МГц - всего 40мкс. И если читать по одному сектору "вразброс" то получим скорость - порядка 512*1K (1000 циклов по 1мс) - всего 512Килобайт. Эта скорость может быть чуть выше или чуть ниже - в-основном зависит от карты, но на двух десятках проверенных мной карт, включая самые новые SDHC, не поднималась выше 2Мбайт/сек.
Другое дело, что контроллер карт очень сильно оптимизирован на операции с последовательными секторами -тут уже скорость может существенно быть выше - при чтении по 32 сектора мне удавалось на SD подняться и до 8Мбайт/сек. Если используется файловая система - то, скорее всего, читать можно будет именно кластерами по нескольку секторов за одну операцию, и оптимизацией контроллера под групповые операции вполне можно воспользоваться.
P.S. Вот результаты испытаний на S2410 - аппаратный контроллер MMC/SD - частота тактирования шины MMC/SD 16.625МГц (и дело было в 2006 - карты были не особо новые)
MMC SD
Теоретическая пропускная способность (max): 2.08MBps 8.31 MBps
Результаты практических испытаний
Чтение по одному 512-байтному блоку: 0.83 MBps 1.79 MBps
Чтение группами по 8 512-байтных блоков: 1.40 MBps 5.41 MBps
Чтение группами по 12 512-байтных блоков: 1.54 MBps 5.70 MBps
Чтение группами по 16 512-байтных блоков: 1.60 MBps 5.81 MBps
Чтение группами по 120 512-байтных блоков: 1.87 MBps 7.78 MBps
Запись по одному 512-байтному блоку: 0.19 MBps 0.42 MBps
Запись группами по 12 512-байтных блоков: 0.40 MBps 1.69 MBps
Такой обьем можно и в ОЗУ кешировать. Если выберете ARM с внешней памятью.
Ну раз разговор зашёл про SD,не стал создавать тему. Спрошу малость не по теме.
Может кто знает, как заставить EFSL не буферить данные. Уменьшил IOMAN_NUMBUFFER до 1-го - но один чёрт не сбрасывает, пока файл опять не откроешь.
Последовательность работы такова:
1) открыть файл
2) записать пару сотен байт
3) закрыть файл
4) вернуться к пункту 1-н
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
Может кто знает, как заставить EFSL не буферить данные. Уменьшил IOMAN_NUMBUFFER до 1-го - но один чёрт не сбрасывает, пока файл опять не откроешь.
Последовательность работы такова:
1) открыть файл
2) записать пару сотен байт
3) закрыть файл
4) вернуться к пункту 1-н
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
Цитата(Wano @ Oct 29 2008, 18:24)
Ну раз разговор зашёл про SD,не стал создавать тему. Спрошу малость не по теме.
Может кто знает, как заставить EFSL не буферить данные. Уменьшил IOMAN_NUMBUFFER до 1-го - но один чёрт не сбрасывает, пока файл опять не откроешь.
Последовательность работы такова:
1) открыть файл
2) записать пару сотен байт
3) закрыть файл
4) вернуться к пункту 1-н
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
Может кто знает, как заставить EFSL не буферить данные. Уменьшил IOMAN_NUMBUFFER до 1-го - но один чёрт не сбрасывает, пока файл опять не откроешь.
Последовательность работы такова:
1) открыть файл
2) записать пару сотен байт
3) закрыть файл
4) вернуться к пункту 1-н
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
EFSL вся из кривостей. Чем быстрее переберешься на FatFS, тем меньше проблем в будущем.
Цитата(Wano @ Oct 29 2008, 16:24)
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.
В FatFS для таких случаев есть функция f_sync():
Цитата
f_sync
The f_sync function flushes the cached information of a writing file.
Description
The f_sync function performs the same process as f_close function but the file is left opened and can continue read/write/seek operations to the file. This is suitable for applications that open files for a long time in writing mode, such as data logger. Performing f_sync of periodic or immediataly after f_write can minimize risk of data loss due to a sudden blackout or an unintentional disk removal. This function is not supported in read-only configuration.
The f_sync function flushes the cached information of a writing file.
Description
The f_sync function performs the same process as f_close function but the file is left opened and can continue read/write/seek operations to the file. This is suitable for applications that open files for a long time in writing mode, such as data logger. Performing f_sync of periodic or immediataly after f_write can minimize risk of data loss due to a sudden blackout or an unintentional disk removal. This function is not supported in read-only configuration.
Так что брось ты эту efsl
FatFS вполне вменяемая FS.
Цитата(zhz @ Oct 29 2008, 20:16)
В FatFS для таких случаев есть функция f_sync():
Так что брось ты эту efsl
FatFS вполне вменяемая FS.
Так что брось ты эту efsl
FatFS вполне вменяемая FS.
Да, только прикрутить к ней буферизацию нормальную.
Прошу помочь растолковать
4.6.2.1 Read
For a Standard Capacity SD Memory Card, the times after which a timeout condition for read operations
occurs are (card independent) either 100 times longer than the typical access times for these
operations given below or 100 ms (the lower of the two). The read access time is defined as the sum
of the two times given by the CSD parameters TAAC and NSAC (see Chapter 5.3). In the case of a
single read operation, these card parameters define the typical delay between the end bit of the read
command and the start bit of the data block. In the case of a multiple-read operation, they also define
the typical delay between the end bit of a data block and the start bit of next data block.
A High Capacity SD Memory Card indicates TAAC and NSAC as fixed values. The host should use 100
ms timeout (minimum) for single and multiple read operations rather than using TAAC and NSAC.
4.6.2.2 Write
For a Standard Capacity SD Memory Card, the times after which a timeout condition for write operations
occurs are (card independent) either 100 times longer than the typical program times for these
operations given below or 250 ms (the lower of the two). The R2W_FACTOR field in the CSD is used
to calculate the typical block program time obtained by multiplying the read access time by this factor. It
applies to all write commands (e.g. SET(CLR)_WRITE_PROTECT, PROGRAM_CSD and the block
write commands).
A High Capacity SD Memory Card indicates R2W_FACTOR as a fixed value.
Maximum length of busy is defined as 250 ms for all write operations. The host should use 250 ms
timeout (minimum) for single and multiple write operations rather than using R2W_FACTOR.
4.6.2.3 Erase
If the card supports parameters for erase timeout calculation in the SD Status, the host should use them
to determine erase timeout (see Chapter 4.10.2). If the card does not support these parameters, erase
timeout can be estimated by block write delay.
The duration of an erase command can be estimated by the number of write blocks (WRITE_BL) to be
erased multiplied by 250 ms.
из упрощенной спецификации SDHC - Simplified_Physical_Layer_Spec.pdf
особенно интересует, действительно ли при записи расчитывать на время занятости 250 мс (!!!)
4.6.2.1 Read
For a Standard Capacity SD Memory Card, the times after which a timeout condition for read operations
occurs are (card independent) either 100 times longer than the typical access times for these
operations given below or 100 ms (the lower of the two). The read access time is defined as the sum
of the two times given by the CSD parameters TAAC and NSAC (see Chapter 5.3). In the case of a
single read operation, these card parameters define the typical delay between the end bit of the read
command and the start bit of the data block. In the case of a multiple-read operation, they also define
the typical delay between the end bit of a data block and the start bit of next data block.
A High Capacity SD Memory Card indicates TAAC and NSAC as fixed values. The host should use 100
ms timeout (minimum) for single and multiple read operations rather than using TAAC and NSAC.
4.6.2.2 Write
For a Standard Capacity SD Memory Card, the times after which a timeout condition for write operations
occurs are (card independent) either 100 times longer than the typical program times for these
operations given below or 250 ms (the lower of the two). The R2W_FACTOR field in the CSD is used
to calculate the typical block program time obtained by multiplying the read access time by this factor. It
applies to all write commands (e.g. SET(CLR)_WRITE_PROTECT, PROGRAM_CSD and the block
write commands).
A High Capacity SD Memory Card indicates R2W_FACTOR as a fixed value.
Maximum length of busy is defined as 250 ms for all write operations. The host should use 250 ms
timeout (minimum) for single and multiple write operations rather than using R2W_FACTOR.
4.6.2.3 Erase
If the card supports parameters for erase timeout calculation in the SD Status, the host should use them
to determine erase timeout (see Chapter 4.10.2). If the card does not support these parameters, erase
timeout can be estimated by block write delay.
The duration of an erase command can be estimated by the number of write blocks (WRITE_BL) to be
erased multiplied by 250 ms.
из упрощенной спецификации SDHC - Simplified_Physical_Layer_Spec.pdf
особенно интересует, действительно ли при записи расчитывать на время занятости 250 мс (!!!)
Кстати, вот идейка:
Проверил скорость работы NAND FLASH MT29F2G08AACWP (256 MByte, 5$ на DigiKey) на ARM9
Чтение происходит с очень стабильной соростью - 8.48 MByte/s
Использовался режим чтения с кэшированием в NAND.
Так файлы можно переписать на NAND и получить очень предсказуемую скорость считывания.
Максимальная скорость считывания c SD карты 60X Apacer была около 5 Mbyte/s
Карта работала в 4-х битном режиме на 26 МГц (дал оверклокинга)
Так что байки насчет 8 MByte/s с SD карт оставим на совести сочинителя.
Проверил скорость работы NAND FLASH MT29F2G08AACWP (256 MByte, 5$ на DigiKey) на ARM9
Чтение происходит с очень стабильной соростью - 8.48 MByte/s
Использовался режим чтения с кэшированием в NAND.
Так файлы можно переписать на NAND и получить очень предсказуемую скорость считывания.
Максимальная скорость считывания c SD карты 60X Apacer была около 5 Mbyte/s
Карта работала в 4-х битном режиме на 26 МГц (дал оверклокинга)
Так что байки насчет 8 MByte/s с SD карт оставим на совести сочинителя.
Цитата(Serg_D @ Oct 28 2008, 16:52)
День добрый!
если у кого есть опыт, был бы весьма признателен за ответ на следующий вопрос:
утрированно задача следующая -
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
из первого файла 16 кило, из второго 16 кило итд, и так по кругу, складывая это в буфера в озу.
Так вот в разрезе этой задачи интересуют оценки сверху по времени на следующие операции -
1 - переключение чтения с одного файла на другой (получается переключение с одногосеткора на другой, для нанд флэши эти данные есть, но ведь в карте свой контроллер)
2 - время открытия файла, если это FAT
А если файлов не 1000 а 64 допустим?
чтение будет требоваться, примерно 3-6 мегабайт в секунду...
Сорри за расплывчатое объяснение, необходимо понять стоит ли покупть отладочную плату для опытов в принципе - или затея изначально не решаемая.
По АРМ-ам - смотрю в сторону атмелов SAM9X или NXP (по перефирии подкупает новая серия 3130, но отладочные платы видимо будут ещё не скоро...), у них есть SDIO - тюе можно получить (видимо) вменяемую скорость...
Спасибо!
если у кого есть опыт, был бы весьма признателен за ответ на следующий вопрос:
утрированно задача следующая -
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
из первого файла 16 кило, из второго 16 кило итд, и так по кругу, складывая это в буфера в озу.
Так вот в разрезе этой задачи интересуют оценки сверху по времени на следующие операции -
1 - переключение чтения с одного файла на другой (получается переключение с одногосеткора на другой, для нанд флэши эти данные есть, но ведь в карте свой контроллер)
2 - время открытия файла, если это FAT
А если файлов не 1000 а 64 допустим?
чтение будет требоваться, примерно 3-6 мегабайт в секунду...
Сорри за расплывчатое объяснение, необходимо понять стоит ли покупть отладочную плату для опытов в принципе - или затея изначально не решаемая.
По АРМ-ам - смотрю в сторону атмелов SAM9X или NXP (по перефирии подкупает новая серия 3130, но отладочные платы видимо будут ещё не скоро...), у них есть SDIO - тюе можно получить (видимо) вменяемую скорость...
Спасибо!
Цитата(AlexandrY @ Nov 2 2008, 00:47)
Максимальная скорость считывания c SD карты 60X Apacer была около 5 Mbyte/s
Экстремально дешовая карточка с действительно мало к чему обязывающими "60X" или другими "X"
Цитата
Так что байки насчет 8 MByte/s с SD карт оставим на совести сочинителя.
А слабо было попробовать карточки отмаркированные не абстрактными и непонятно к чему обязывающими наклейщика этикеток "Apacer" письменами 60X, а маркированые официально, как SDHC Class 2/4/6/8 ? Причем встречал для любителей X карточку SDHC Class 6 дополнительно маркированную, как 133X
Так, турбировал NAND. Неплохо держит до 43 МГц при штатных 33 МГц
Скорость чтения при этом 13.2 MByte/s.
Apacer 60X действительно мутная штука. Для двух карт с одинаково написанными 60X был разный параметр SD data_read_access_time1 из области Card-Specific Data register (CSD)
У одной 0.02 у другой 0.005.
Тема не закрыта. Насчет быстродействия непосредственно FAT на этих картах сообщу позже.
SDHC проверить не смогу ибо у меня интерфейс SDIO специфицирован на 25 МГц. Т.е. на нем самая быстрая карта не потянет больше 12.5 Mbyte/s в пределе.
Вот USB HS флеши можно попробывать. Но это когда поднимется соответствующая тема
Скорость чтения при этом 13.2 MByte/s.
Apacer 60X действительно мутная штука. Для двух карт с одинаково написанными 60X был разный параметр SD data_read_access_time1 из области Card-Specific Data register (CSD)
У одной 0.02 у другой 0.005.
Тема не закрыта. Насчет быстродействия непосредственно FAT на этих картах сообщу позже.
SDHC проверить не смогу ибо у меня интерфейс SDIO специфицирован на 25 МГц. Т.е. на нем самая быстрая карта не потянет больше 12.5 Mbyte/s в пределе.
Вот USB HS флеши можно попробывать. Но это когда поднимется соответствующая тема
Цитата(zltigo @ Nov 2 2008, 03:24)
Экстремально дешовая карточка с действительно мало к чему обязывающими "60X" или другими "X"
А слабо было попробовать карточки отмаркированные не абстрактными и непонятно к чему обязывающими наклейщика этикеток "Apacer" письменами 60X, а маркированые официально, как SDHC Class 2/4/6/8 ? Причем встречал для любителей X карточку SDHC Class 6 дополнительно маркированную, как 133X
А слабо было попробовать карточки отмаркированные не абстрактными и непонятно к чему обязывающими наклейщика этикеток "Apacer" письменами 60X, а маркированые официально, как SDHC Class 2/4/6/8 ? Причем встречал для любителей X карточку SDHC Class 6 дополнительно маркированную, как 133X
Цитата(AlexandrY @ Nov 3 2008, 21:56)
SDHC проверить не смогу ибо у меня интерфейс SDIO специфицирован на 25 МГц. Т.е. на нем самая быстрая карта не потянет больше 12.5 Mbyte/s в пределе.
Тем не менее это много больше, нежели 5Mbyte/s в которую уперлась НЕ SDHC карточка неведомого производителя с наклейкой от Apacer.
Вопрос попутный - я правильно понимаю что если использовать CompactFlash карты, то с предсказуемостью чтения (да и со скоростью) будет по-лучше?
Правда отладочные платки ARM9 и CF сейчас не в ходу смотрю, нашел только тион, но циррус по перефирии не подходит...
Правда отладочные платки ARM9 и CF сейчас не в ходу смотрю, нашел только тион, но циррус по перефирии не подходит...
Цитата(Serg_D @ Nov 4 2008, 23:51)
Вопрос попутный - я правильно понимаю что если использовать CompactFlash карты, то с предсказуемостью чтения (да и со скоростью) будет по-лучше?
Нет.
Отчет по времени выполнения файловых операций чтения на SD картах здесь:
http://aly.ogmis.lt/OpenProjects/ARMUltima...ote4/FSTest.htm
http://aly.ogmis.lt/OpenProjects/ARMUltima...ote4/FSTest.htm
спасибо!
однако открытие до 60 милисекунд если я на ночь глядя ничего не напутал...
однако открытие до 60 милисекунд если я на ночь глядя ничего не напутал...
Быстрая многозадачная FAT штука достаточно сложная с хитрым кэшированием.
Еще немного турбировал, подрегулировал буфера и несколько улучшил результаты.
Теперь файловая система требует RAM-а для буферов больше мегабайта, но я реализовал вашу идею насчет одновременно открыть 1000 файлов.
Результаты смотрите в том же файле по ссылке.
Оказалось не так опасно как предпологал.
Система не валится.
Даже оказалось что уже открытые файлы в среднем читаются несколько быстрее чем в обычной последовательности.
Но среднее время открытия при открытии всех файлов сразу замедляется как и предпологал.
Кажущееся неоправданно большим время закрытия объясняется тем, что система делает много проверок на валидность, доступ из других задач, освобождений блокируемого многозадачного heap-а и блокировок. Тоже самое можно наблюдать в Windows при работе с файлами на SD.
Короче, предсказуемость и скорость чтения достаточны и ваша первоначальная идея вполне может быть реализована, и моя тоже
Еще немного турбировал, подрегулировал буфера и несколько улучшил результаты.
Теперь файловая система требует RAM-а для буферов больше мегабайта, но я реализовал вашу идею насчет одновременно открыть 1000 файлов.
Результаты смотрите в том же файле по ссылке.
Оказалось не так опасно как предпологал.
Система не валится.
Даже оказалось что уже открытые файлы в среднем читаются несколько быстрее чем в обычной последовательности.
Но среднее время открытия при открытии всех файлов сразу замедляется как и предпологал.
Кажущееся неоправданно большим время закрытия объясняется тем, что система делает много проверок на валидность, доступ из других задач, освобождений блокируемого многозадачного heap-а и блокировок. Тоже самое можно наблюдать в Windows при работе с файлами на SD.
Короче, предсказуемость и скорость чтения достаточны и ваша первоначальная идея вполне может быть реализована, и моя тоже
Цитата(Serg_D @ Nov 6 2008, 03:48)
спасибо!
однако открытие до 60 милисекунд если я на ночь глядя ничего не напутал...
однако открытие до 60 милисекунд если я на ночь глядя ничего не напутал...
т.е то что вы сейчас реализовали - это примерно равносильно тому чтоб читать из одного, допустим гигабайтного файла в случайном порядке с разных мест?
Более того - с 10-и гигабайтного файла!
Еще поддать только RAM-а мега на два и можно открывать и 2-е и 3-и тысячи файлов.
Поскольку на старт операции чтения открытого файла не было замечено влияния количества открытых файлов.
Впрочем в отчете достаточно статистики чтобы вы сами могли найти корреляции и их доверительные оценки.
Еще поддать только RAM-а мега на два и можно открывать и 2-е и 3-и тысячи файлов.
Поскольку на старт операции чтения открытого файла не было замечено влияния количества открытых файлов.
Впрочем в отчете достаточно статистики чтобы вы сами могли найти корреляции и их доверительные оценки.
Цитата(Serg_D @ Nov 6 2008, 19:12)
т.е то что вы сейчас реализовали - это примерно равносильно тому чтоб читать из одного, допустим гигабайтного файла в случайном порядке с разных мест?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.