Проведено (http://www.setupc.ru/wiki/moin.cgi/ssd_test_x25m) тестирование производительности твердотельного диска (Solid State Disk) Intel X25-m G1. Тестирование проводилось при помощи утилиты iozone (http://www.iozone.org/), на системе с Linux ядром 2.6.31.6 и Файловой системой ext3 с параметрами по умолчанию. Для уменьшения влияния планировщика ввода-вывода на результаты тестирование проводилось в режиме с elevator=noop. Для отключения файловых кешей Linux использовались опции "iozone -o -I". Эти опции приводят к установке флагов O_SYNC и O_DIRECT при открытии файлов
Показана зависимость скорости чтения-записи от размера файла и размера запрашиваемого блока. Так же продемонстрирована зависимость скорости работы диска от количества одновременно запущенных процессов.
Результаты тестирования демонстрируют основные преимущества твердотельных накопителей в сравнении с традицонными HDD.URL: http://www.setupc.ru/wiki/moin.cgi/ssd_test_x25m
Новость: http://www.opennet.me/opennews/art.shtml?num=24935
Очень интересно, спасибо за статью.
Форониксу есть на кого равняться)
http://www.anandtech.com/storage/IMHO там более полные и понятные выкладки.
>http://www.anandtech.com/storage/
>
>IMHO там более полные и понятные выкладки.Буду рад увидеть тут новость с сылкой на статью оттуда)
А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
немного приправленоа маркетинговым булщитом.
После тестов должны быть видны достоинства и недостатки.
если недостатков нет, то это тупая заказуха.
>А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
>немного приправленоа маркетинговым булщитом.
>После тестов должны быть видны достоинства и недостатки.
>если недостатков нет, то это тупая заказуха.Если честно, я даже не смотрел на эти "Kbytes/sec".
Я смотрел на зависимость скорости от размера блока данных, от размера копируемого файла, от количества одновременных процессов.
Именно от этих параметров зависит скорость работы приложений, работающих с файлами.Но не все это понимают.
Например, судя по статье, разница между блоком в 4кб и 128кб различается в разы.
Что это означает на практике?
Это значит, что можно увеличить быстродействие какой-то системы на десятки или сотни процентов, прописав оптимальные значения.
Без затрат средств на обновление аппаратного обеспечения.А "Kbytes/sec" - это да, это сферично.
Если быстродействие упирается именно в этот показатель, тут только менять дисковую подсистему.
Больше месяца прошло. Это уже какой-то некропостинг получится :)Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.
>Больше месяца прошло. Это уже какой-то некропостинг получится :)
>
>Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.Согласен.
Я вот про этот сайт не знал.
Буду рад увидеть тут новости про интересные и полезные статьи оттуда)
быстрее чем на винде. круто
Чего в этом удивительного?
Ура Ultra320SCSI Рулит, 93 Mb/sec на запись!!!Интересно другое...
> max UDMA/133
А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...SATA-II 3Gbps где неувязка?
в диагноститеском сообщении драйвера, что он может общаться с девайсом ata командами?
>>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
>
>SATA-II 3Gbps где неувязка?
>в диагноститеском сообщении драйвера, что он может общаться с девайсом ata командами?
>SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег, мы крутые как яйцы бобра...
Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше - 3e9/8 = 375 Mb/sec.
Во вторых, это скорость на проводе, - между чипсетом и контроллером на диске.
По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.
Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.
Планировщики ввода/вывода, планировщики задач, сискалы... и т.п.
За счёт больших кэшей, можно добиться реальных 50% скорости, от рекламных.
За счёт рисования бенчмарков, можно добиться реальных 75% скорости, от рекламных.В реальности 10-15% при записи, ну и до 40% на чтение.
Бенчмарки дело третье... из этого бенча http://www.setupc.ru/wiki/moin.cgi/ssd_test_x25m?action=Atta...
random read везде быстрее :), 1 из 2-х - либо пиз...т, либо random number generator плохой.
Если не секрет - что идёт лишнего "от чипсетов, оператифки" по SATA шине ? ECC идёт отдельно от кодирования ? Что добивает ОСь ? Что вы курили когда писали этот пост ?
>SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег, мы крутые как яйцы >бобра...
>Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше - 3e9/8 = 375 Mb/sec.
>Во вторых, это скорость на проводе, - между чипсетом и контроллером на диске.
>По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.
>Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.глупости вы пишите. На той же самой сетевухе, маркированной 1ГБ, вы этот ГигаБит и получите. Не верите? Отключите qos udp, icmp и проверьте :))) И нет там никаких наводок видимых. Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".
По теме. Согласен, что цифры бесполезные. Почему? Честно? Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу вечером внезапно клиенты начали звонить - место кончилось :)))
> Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".Ага ага... :)
Маркировка даётся с учётом стандартов.
Многие сетевухи на 10/100 давно уже умеют и 130Mb и 160Mb,
гигабитный Интел может 1.12Gb, а Noname RTL8169 еле 750 поднимает, попадаются на оборот...
>
> Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу
>вечером внезапно клиенты начали звонить - место кончилось :)))Их туда врубают для кэшей, свопов, $TMPDIR, и прочего часто обновляющесяго...
хотел бы я посмотреть на сервер у которого каталог /tmp на ssd
и как он через год зависнет по причине исчерпания ресурса перезаписываний
> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты про кодирование 8 к 10 в SATA интерфейсе никогда не слышал? Хорошо бы услышать было, при том - *до* проведения столь кульных вычислений :P.
>> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
>
>Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты
>про кодирование 8 к 10 в SATAНе в 8 к 10, а 8B/10B... что не легче, значит SATA быстрый модем :) - 8 бит данных, 1 чётность., 1 стоповый.
>>> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
>>
>>Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты
>>про кодирование 8 к 10 в SATA
>
>Не в 8 к 10, а 8B/10B... что не легче, значит SATA
>быстрый модем :) - 8 бит данных, 1 чётность., 1
>стоповый.Мне вот интересно, это только я один догадался в википедию заглянуть и почитать что собой представляет 8b/10b кодирование?
http://en.wikipedia.org/wiki/8b/10b_encoding
PS павлинух - мимо утки.
PPS Lindemidux - тоже мимо
>[оверквотинг удален]
>>>про кодирование 8 к 10 в SATA
>>
>>Не в 8 к 10, а 8B/10B... что не легче, значит SATA
>>быстрый модем :) - 8 бит данных, 1 чётность., 1
>>стоповый.
>
>Мне вот интересно, это только я один догадался в википедию заглянуть и
>почитать что собой представляет 8b/10b кодирование?
>http://en.wikipedia.org/wiki/8b/10b_encoding
>Ну и чё ты выпиндрился...
Мы эти кодирования ещё в децком саду проходили, Википедии тогда не было, по "Теории информации"
И ваще, задолбали своей Википедией, у самих мозг остался?!Не, коль такой вумный, нарисуй закодированую строку из 4 байт
8B
11111111 -
10101010 -
10100111 -
11001101 -А таком виде - ~|________|~, где: "_|~" - малый потенциал, пусть будет 0, "~|_" - 1,
>Мы эти кодирования ещё в децком саду проходили, Википедии тогда не было,
>по "Теории информации"Остынь павлинух. Мы тоже проходили, и что с этого?
>И ваще, задолбали своей Википедией, у самих мозг остался?!
Просто если я пишу что-то в чём не уверен, то стараюсь проверить информацию насколько это возможно. Запрос в гугль выдал статью в педовикии в которой всё было написано английским по белом - никаких стопов, чётности и прочей фигни. На всё про всё - пару мин, и никаких ошибок. Так что павлинух иногда всё же лучше жевать, а если указали на ошибку - то тем более.
Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих целей.
>Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих
>целей.Так по проводу они всё равно летают, от чипсета до диска?!
>Так по проводу они всё равно летают, от чипсета до диска?!Павлин, не тормози, 2 лишних бита - именно для передачи по проводу и есть.
>SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег,
>мы крутые как яйцы бобра...Иногда лучше жевать.
>Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше
>- 3e9/8 = 375 Mb/sec.Вообще-то в 10. В sata пользуют 8b/10b кодирование
>Во вторых, это скорость на проводе, - между чипсетом и контроллером на
>диске.Угу.
>По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.
Там синхронный канал, так что latency там фиксировано и никакой роли при потоковой передаче не играет. ecc там нет вроде как (его не было в pata, и тут скорее всего нет).
>Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.
Вы почитайте что такое dma и bus master. Посчитайте сколько ваша оперативка пропустить через себя может. Мелочи это всё.
>Планировщики ввода/вывода, планировщики задач, сискалы... и т.п.
Он такой тормознутый?
>> max UDMA/133
>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я думал глубокий физический смысл - в 3GBps линке, сырая скорость которого 300Мбайт в секунду...
>>> max UDMA/133
>>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
>
>Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я
>думал глубокий физический смысл - в 3GBps линке, сырая скорость которого
>300Мбайт в секунду...Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...
Такие скорости у 15000 rpm SAS на на оптике...
>Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL
>базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...А где там скорость в 300Мб/с была? Это скорость (сферического) потока (в вакууме) со всеми командами, максимальная из того что возможно в теории по этому интерфейсу. Ессно в реальном случае будет куча оверхеда и реальная скорость будет 200 с чем-то. При условии что девайс со своей стороны не тормозит.
>Такие скорости у 15000 rpm SAS на на оптике...Ты хочешь сказать что у них скорость записи на блины выше 300 мегов в секунду у в случае SAS с обычным SATAшным физическим уровнем упирается именно в него а не в тормознутую механику? Тем более что если твой 15000 RPMовый не дай боже заложит пару seek'ов - ждать придется МИЛЛИСЕКУНДЫ на каждый seek. Как и в старые добрые времена. Ну механика же. А вот флеш - знаешь, адрес куда запись происходит сменить это не физические головы в другой конец диска загнать. Да и при чтении такая же байда. Отсюда и потенциальный выигрыш.
> Ты хочешь сказать что у них скорость записи на блины выше 300 меговЭто ты сказать хочешь, а мне на интерфейс насрать, но если прикалывает
FC SAS = 4Gb/s, SAS-II = 6Gb/s, FC SAS-II 8Gb/s - см. Qlogic 2560
А реальная скорость записи у FC SAS диска 105Mb/s
На чтение да, уже проигрывают ... со счётом 1:2
> Отсюда и потенциальный выигрыш.Где выигрыш? Йопнулся что ля ... 60 Mb/s на запись????
У мня дома старый ASC 29320A и Maxtor Atlas II на 15k, и то даёт
93 Mb/s WRITE
84 Mb/s RANDOM WRITE
>Это ты сказать хочешь, а мне на интерфейс насрать, но если прикалывает
> FC SAS = 4Gb/s, SAS-II = 6Gb/s, FC SAS-II 8Gb/s -
>см. Qlogic 2560Это гигаБиты? А то SATA с 6Гбит уже на подходе.
>А реальная скорость записи у FC SAS диска 105Mb/s
А что, 105 мб/сек считается чем-то крутым? Столько нынче SOHOвские диски выжимают. У 15 000 rpm основной выигрыш в времени seek, в общем то. Как бы чем быстрее диски крутятся тем быстрее после загона головы в нужное место нужный сектор под ней пролетит.
>Где выигрыш?
При нагрузке с большой фрагментацией?
>Йопнулся что ля ... 60 Mb/s на запись????
>У мня дома старый ASC 29320A и Maxtor Atlas II на 15k,
> и то даёт
>93 Mb/s WRITE
>84 Mb/s RANDOM WRITEЗаставь диски гонять головы туда-сюда соответствующей нагрузкой и посмотри что останется от этих мегов в секунду :).Чудес не бывает - механический прогон голов тудаю-сюда время требует, а у флешатины гонять нечего, адрес сменить быстро. А запись у флеша тоормзная, ты как к ней избирательно прикопался, да? Разумеется, если нагрузка с интненсивной записью, не очень фрагментированная и в большом объеме - лучше флеш не юзать. А то еще и протрется чего доброго до дыр - циклов перезаписи оно выдерживает не так уж и много :)
В версии G1 вроде TRIM не поддерживался .
Вопрос к автору : со временем нет ухудшения в скорости записи ?
Да, в G1 нету TRIM ... постараюсь в ближайшее время погонять G2.За скоростью понаблюдаю в процессе эксплуатации. Пока только тесты гонял ... :)
Интересно, а как результаты тестов этой вещи будут отличаться, если ядро и файловая система будут использоваться более новые? А то ведь и ext4 достаточно давно существует и ядро 2.6.32 и даже релизы 2.6.33 разные во всю уже существуют и я читал, что все это имеет немало усовершенствований (прогресс) по сравнению с тем, что тут приведено
Ок, попробую с более новым ядром. Теоретически ничего не должно поменяться - в тесте влияние ядра сведено к минимуму, да и показанные результаты очень близки к заявленным производителем ( 250 МБ/сек на чтение и 70 МБ/сек на запись ).
SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G ) , FW 8790
RANDOM READ TESTS .
10 Files ( 1 GB each) and 10 reading processes
CFQ 20046 KBps
Deadline 49169 KBps4 Files ( 1 GB each) and 4 reading processes
CFQ 48966 KBps
Deadline 50697 KBps1 FILE ( 50 GB ) and one reader process
CFQ 78849 KBps
Deadline 79203 KBpsCentos 5.2 , iosched/fifobatch set to 1 .
>SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G ) ,
>FW 8790
>RANDOM READ TESTS .record size = 50 kb , ( специфика нашей аппликации )
Похоже не быстро даже для "record size = 50 kb", хотя x25e вроде как более "продвинутый" относительно x25m. По моим графикам при таком размере блока скорость "random read" около 120 МБ/сек.Поглядите, может NCQ отключен (dmesg | grep NCQ) ? Без NCQ скорость чтения заметно падает ( наблюдаю падение с 250 МБ/сек до 180 МБ/сек т.е. примерно -30% ).
я неправильно читаю график или действительно для блоков размером менее 128кб/с random write намного быстре sequential write?
да, так и есть. объясняется это скорее всего тем, что при записи контроллер может писать только блоками по 128 КБ (или более). При этом при последовательной записи если в блоке уже есть данные, то контроллеру необходимо их считать, добавить к ним новые данные и записать обратно.При рандомной записи таких ситуаций возникает меньше т.к. есть вероятность, что часть данных будет записана в блок размером 128КБ один раз.
