SD vs MMC

[ВадимП]

На случай, если это кому-то интересно привожу результаты тестирования скорости ЗАПИСИ на различные карты на том же КПК Zaurus SL-C760

тестировалась также "сырая" (без учета влияния файловой системы) скорость записи, кэширование не использовалось.
Тестирование осуществлялось командой time dd if=/dev/zero of=/dev/<устройство> count=64k bs=1k

Были получены вполне ожидаемые результаты:

Код: Выделить всё

--------------------------------------------
карта            | real   | system |  user |
-----------------+--------+--------+--------
cf sandisk 512MB | 46.584 |  6.050 | 0.130 |
sd sandisk 512MB | 66.826 |  5.040 | 0.020 |
mmc noname 128MB |126.450 |  4.380 | 0.050 |
--------------------------------------------

т.е. относительная скорость карт осталась прежней cf (1407kBps) > sd (981kBps) > mmc (518kBps).
Определенное удивление может вызвать только заметное снижение загрузки процессора: для cf-карты она упала с 41.5% до 13.2%.

P.S. Операция проводилась на демонтированных картах, хотя cf-карта была при этом подключена - в противном случае КПК просто обесточивает разъем.
P.P.S. Я надеюсь всем абсолютно ясно, что такое тестирование полностью разрушает не только файловую систему, но и MBR вместе с таблицей разделов?

[ВадимП]

P.P.P.S. Все приведенные выше "тесты" не претендуют на репрезентативность. Я сам в этой теме с сомнением отзывался о тестах других людей, могу с сомнением отозваться и о своих собственных. Самые большие нарекания здесь могут быть к тесту записи - для чистоты эксперимента надо было бы расписывать карту не нулями, а случайно генерированнымы числами. Но сделать это несколько сложнее: если сначала создать тестовый файл со случайными числами (или просто сжать архиватором любой файл, что то же самое) то этот файл надо будет где-то располагать. Поместить его во внутреннем флеше нереально - даже несмотря на значительно большую производительность NAND в результаты тестирования вкрадется значительная погрешность связанная с временем чтения этого файла из флеш-памяти. Поместить на электронном диске тоже не выйдет - Zaurus имеет только 64MB RAM и 64-мегабайтный файл полностью в ОЗУ явно не разместишь. Конечно, можно было бы перемонтировать 10MB shm-файловую систему в 32 мегабайтную и тестировать файл меньшего размера. Но к такому способу тоже можно предъявить немало претензий, связанных с фактическим изменением доступной ОС оперативной памяти.
Наконец, можно было генерировать случайные числа непосредственно в момент записи, заменив параметр "of=/dev/zero" на "of=/dev/urandom" ("of=/dev/random", очевидно, не может использоваться в силу крайне незначительной энтропии любой реальной компьютерной системы). Но я не возьмусь предсказать загрузку процессора на выполнение этой операции (никогда не смотрел исходных текстов драйвера этого устройства, хотя нетрудно предположить, что используется линейный конгруэнтный алгоритм). Поэтому таким путем я тоже не пошел. На самом деле, я не думаю, что запись нулей по времени как-то реально отличается от записи произвольных данных. Хотя, если бы я тестировал то же самое с учетом влияния файловой системы, то результаты оказались бы принципиально иными. Особенно на jffs2.

[ВадимП]

p.p.p.p.s. Зато из всего вышеизложенного прекрасно видно почему нет никакого смысла пытаться тестировать что-то на card-reader'е с интерфейсом usb 1.1: даже в какой-то немыслимой теории, в которой мы полностью пренебрегаем какой бы то ни было служебной информацией на usb-шине и предполагаем, что все ее 12Mbps составляет исключительно поток данных с флеш-карты, даже тогда ее пропускной способности хватает только на обслуживание mmc. Все остальные вынуждены ждать шину. Реально же, увы, и на mmc, как легко заметить, ее не хватает тоже. Поэтому не только мой, но и любой "тест" карт на usb 1.1 reader'е не стоит даже той бумаги на которой он напечатан.

[Ультрафиолетовый бегемот]

Как-то раз, увидев у знакомого карточку SD на 256Мб от Sandisk, ради интереса сравнил со своей аналогичного объёма от SimpleTech. Сравнивал с помощью програмы VFS Mark, которую взял здесь в разделе "Программы". К сожалению, я тогда не записал результаты теста карты Sandisk, потому как находился в лёгком шоке от несопоставимо меньшего рейтинга этой карточки. Самое интересное, что позже, когда я покупал карточку знакомому для ТТ (SD) и себе для камеры (CF), мне посоветовали не брать карты от Sandisk, ни ту ни другую. Вот вам и разработчик, вот вам и законодатель...
__________________________________
TT + SD256 SimpleTech

[Anonymoussssss]

>Тестирование осуществлялось командой time dd if=/dev/zero of=/dev/<устройство> count=64k bs=1k

меня слегка смущает bs=1k

на своем Palm Zire 71 + SD Digitex, 256Mb (SH256 Panasonic) с помощью CardSpeed 1.2 получены следующие результаты
(NumFiles 1, FileSize 10`000`000)


ChunkSize 1024 (1 kb)
Read 802 Kb/sec
Write 32 Kb/sec

ChunkSize 4096 (4 kb)
Read 1760 Kb/sec
Write 116 Kb/sec


ChunkSize 8192 (8 kb)
Read 2205 Kb/sec
Write 240 Kb/sec


ChunkSize 16384 (16 kb)
Read 2402 Kb/sec
Write 342 Kb/sec


ChunkSize 32768 (32 kb)
Read 2591 Kb/sec
Write 650 Kb/sec

наверняка дело не только в зарузке процессора

[ВадимП]

Я не думаю, что величина bs может оказать какое-то заметное влияние.
Это же все-таки сырая запись физических блоков, а не запись средствами файловой системы.

1k (1024байт) был выбран на основании строго научного принципа, известного в народе как принцип "от балды".
Главное, что он кратен размеру физического блока. Будет свободное время, проверю и опубликую на одной какой-нибудь карте результаты с "bs=512 count=128k" и "bs=2k count=32k"

[Anonymoussssss]

>"bs=2k count=32k"
IMXO, интересней наоборот "bs=32k count=2k"
>Я не думаю, что величина bs может оказать какое-то заметное влияние.
ну, не знаю, у меня раздница получилась ~20 раз-
-конечно Texas Instruments OMAP 310,311 144 МГц это не
Intel XScale PXA255 400 МГц, а нагрузка на CPU пропорциональна количеству блоков и, следовательно, обратно пропорциональна их размеру...