| 1.1, XoRe (ok), 15:02, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Очень интересно, спасибо за статью.
Форониксу есть на кого равняться)
| | |
| |
| |
| |
| 4.7, anonymous (??), 19:03, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
немного приправленоа маркетинговым булщитом.
После тестов должны быть видны достоинства и недостатки.
если недостатков нет, то это тупая заказуха.
| | |
| |
| 5.27, XoRe (ok), 20:00, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А зачем? Синтетические тесты в стиле фороникса, только под офтопик.
>немного приправленоа маркетинговым булщитом.
>После тестов должны быть видны достоинства и недостатки.
>если недостатков нет, то это тупая заказуха.
Если честно, я даже не смотрел на эти "Kbytes/sec".
Я смотрел на зависимость скорости от размера блока данных, от размера копируемого файла, от количества одновременных процессов.
Именно от этих параметров зависит скорость работы приложений, работающих с файлами.
Но не все это понимают.
Например, судя по статье, разница между блоком в 4кб и 128кб различается в разы.
Что это означает на практике?
Это значит, что можно увеличить быстродействие какой-то системы на десятки или сотни процентов, прописав оптимальные значения.
Без затрат средств на обновление аппаратного обеспечения.
А "Kbytes/sec" - это да, это сферично.
Если быстродействие упирается именно в этот показатель, тут только менять дисковую подсистему.
| | |
|
| 4.18, _Vitaly_ (ok), 01:19, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Больше месяца прошло. Это уже какой-то некропостинг получится :)
Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.
| | |
| |
| 5.26, XoRe (ok), 19:35, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Больше месяца прошло. Это уже какой-то некропостинг получится :)
>
>Видимо, не все знают про anandtech, вот и изобретают SSD-велосипеды.
Согласен.
Я вот про этот сайт не знал.
Буду рад увидеть тут новости про интересные и полезные статьи оттуда)
| | |
|
|
|
|
| 1.5, pavlinux (ok), 17:23, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ура Ultra320SCSI Рулит, 93 Mb/sec на запись!!!
Интересно другое...
> max UDMA/133
А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
| | |
| |
| 2.8, anonymous (??), 19:07, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
SATA-II 3Gbps где неувязка?
в диагноститеском сообщении драйвера, что он может общаться с девайсом ata командами?
| | |
| |
| 3.9, pavlinux (ok), 19:44, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>А скорость на чтение в тесте 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=AttachFile&do=get&tar
random read везде быстрее :), 1 из 2-х - либо пиз...т, либо random number generator плохой.
| | |
| |
| 4.10, Аноним (-), 20:57, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
Если не секрет - что идёт лишнего "от чипсетов, оператифки" по SATA шине ? ECC идёт отдельно от кодирования ? Что добивает ОСь ? Что вы курили когда писали этот пост ?
| | |
| 4.11, pro100master (ok), 21:00, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>SATA link up 3.0 Gbps - рекламная фишка, ПиаР, понты, дайте денег, мы крутые как яйцы >бобра...
>Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше - 3e9/8 = 375 Mb/sec.
>Во вторых, это скорость на проводе, - между чипсетом и контроллером на диске.
>По обе стороны провода идут кодирование, ECC, latency и прочие полезные фишки.
>Далее идут добавки от чипсетов, оператифки, и наконец, добивает всё OСь.
глупости вы пишите. На той же самой сетевухе, маркированной 1ГБ, вы этот ГигаБит и получите. Не верите? Отключите qos udp, icmp и проверьте :))) И нет там никаких наводок видимых. Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".
По теме. Согласен, что цифры бесполезные. Почему? Честно? Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу вечером внезапно клиенты начали звонить - место кончилось :)))
| | |
| |
| 5.15, pavlinux (ok), 00:41, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Маркировка даётся уже с учетом всех "наводок", "latency и прочие полезные фишки".
Ага ага... :)
Маркировка даётся с учётом стандартов.
Многие сетевухи на 10/100 давно уже умеют и 130Mb и 160Mb,
гигабитный Интел может 1.12Gb, а Noname RTL8169 еле 750 поднимает, попадаются на оборот...
>
> Ну да, на сервер самое милое дело ssd врубить, чтобы через 3 месяца в субботу
>вечером внезапно клиенты начали звонить - место кончилось :)))
Их туда врубают для кэшей, свопов, $TMPDIR, и прочего часто обновляющесяго...
| | |
| |
| 6.39, ABorland (?), 06:24, 19/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
хотел бы я посмотреть на сервер у которого каталог /tmp на ssd
и как он через год зависнет по причине исчерпания ресурса перезаписываний
| | |
|
|
| 4.12, User294 (ok), 21:46, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты про кодирование 8 к 10 в SATA интерфейсе никогда не слышал? Хорошо бы услышать было, при том - *до* проведения столь кульных вычислений :P.
| | |
| |
| 5.16, pavlinux (ok), 00:46, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Во первых там БИТ/сек., как в сетевушке, т.е. в 8 раз меньше -
>
>Эпик фэйл! Вот уж от кого не ожидал... oO. Павлин, а ты
>про кодирование 8 к 10 в SATA
Не в 8 к 10, а 8B/10B... что не легче, значит SATA быстрый модем :) - 8 бит данных, 1 чётность., 1 стоповый.
| | |
| |
| 6.30, Aleksey Salow (ok), 07:02, 10/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >>> Во первых там БИТ/сек., как в сетевушке, т.е. в 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 - тоже мимо
| | |
| |
| 7.34, pavlinux (ok), 15:22, 10/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>>про кодирование 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,
| | |
|
|
|
| 4.22, Lindemidux (??), 15:49, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих целей.
| | |
| |
| 5.23, pavlinux (ok), 16:46, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Ути-пути толстенький, читай спецификацию SATA, там 2 бита служебных специально для этих
>целей.
Так по проводу они всё равно летают, от чипсета до диска?!
| | |
| |
| 6.24, User294 (ok), 16:57, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Так по проводу они всё равно летают, от чипсета до диска?!
Павлин, не тормози, 2 лишних бита - именно для передачи по проводу и есть.
| | |
|
|
| 4.29, Aleksey Salow (ok), 06:54, 10/01/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>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. Посчитайте сколько ваша оперативка пропустить через себя может. Мелочи это всё.
>Планировщики ввода/вывода, планировщики задач, сискалы... и т.п.
Он такой тормознутый?
| | |
|
|
| 2.13, User294 (ok), 21:49, 08/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> max UDMA/133
>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я думал глубокий физический смысл - в 3GBps линке, сырая скорость которого 300Мбайт в секунду...
| | |
| |
| 3.17, pavlinux (ok), 00:51, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>> max UDMA/133
>>А скорость на чтение в тесте 240Mb/sec., чёй-то неувязочка...
>
>Думаешь, это сообщение в данном случае несет глубокий физический смысл? А я
>думал глубокий физический смысл - в 3GBps линке, сырая скорость которого
>300Мбайт в секунду...
Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...
Такие скорости у 15000 rpm SAS на на оптике...
| | |
| |
| 4.25, User294 (ok), 17:01, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Хоть сырая, хоть мокрая .... ну не будет девайс писать 120Gb SQL
>базу или 5 BR-ROM со скоростью 300Mb/s, хоть ты пукни...
А где там скорость в 300Мб/с была? Это скорость (сферического) потока (в вакууме) со всеми командами, максимальная из того что возможно в теории по этому интерфейсу. Ессно в реальном случае будет куча оверхеда и реальная скорость будет 200 с чем-то. При условии что девайс со своей стороны не тормозит.
>Такие скорости у 15000 rpm SAS на на оптике...
Ты хочешь сказать что у них скорость записи на блины выше 300 мегов в секунду у в случае SAS с обычным SATAшным физическим уровнем упирается именно в него а не в тормознутую механику? Тем более что если твой 15000 RPMовый не дай боже заложит пару seek'ов - ждать придется МИЛЛИСЕКУНДЫ на каждый seek. Как и в старые добрые времена. Ну механика же. А вот флеш - знаешь, адрес куда запись происходит сменить это не физические головы в другой конец диска загнать. Да и при чтении такая же байда. Отсюда и потенциальный выигрыш.
| | |
| |
| 5.28, pavlinux (ok), 20:37, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Ты хочешь сказать что у них скорость записи на блины выше 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
| | |
| |
| 6.36, User294 (ok), 21:30, 10/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Это ты сказать хочешь, а мне на интерфейс насрать, но если прикалывает
> 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
Заставь диски гонять головы туда-сюда соответствующей нагрузкой и посмотри что останется от этих мегов в секунду :).Чудес не бывает - механический прогон голов тудаю-сюда время требует, а у флешатины гонять нечего, адрес сменить быстро. А запись у флеша тоормзная, ты как к ней избирательно прикопался, да? Разумеется, если нагрузка с интненсивной записью, не очень фрагментированная и в большом объеме - лучше флеш не юзать. А то еще и протрется чего доброго до дыр - циклов перезаписи оно выдерживает не так уж и много :)
| | |
|
|
|
|
|
| 1.14, rstone (??), 21:54, 08/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В версии G1 вроде TRIM не поддерживался .
Вопрос к автору : со временем нет ухудшения в скорости записи ?
| | |
| |
| 2.20, aospan (?), 12:22, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Да, в G1 нету TRIM ... постараюсь в ближайшее время погонять G2.
За скоростью понаблюдаю в процессе эксплуатации. Пока только тесты гонял ... :)
| | |
|
| 1.19, ua9oas (?), 07:17, 09/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Интересно, а как результаты тестов этой вещи будут отличаться, если ядро и файловая система будут использоваться более новые? А то ведь и ext4 достаточно давно существует и ядро 2.6.32 и даже релизы 2.6.33 разные во всю уже существуют и я читал, что все это имеет немало усовершенствований (прогресс) по сравнению с тем, что тут приведено
| | |
| |
| 2.21, aospan (?), 12:26, 09/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ок, попробую с более новым ядром. Теоретически ничего не должно поменяться - в тесте влияние ядра сведено к минимуму, да и показанные результаты очень близки к заявленным производителем ( 250 МБ/сек на чтение и 70 МБ/сек на запись ).
| | |
|
| 1.31, rstone (??), 11:23, 10/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G ) , FW 8790
RANDOM READ TESTS .
10 Files ( 1 GB each) and 10 reading processes
CFQ 20046 KBps
Deadline 49169 KBps
4 Files ( 1 GB each) and 4 reading processes
CFQ 48966 KBps
Deadline 50697 KBps
1 FILE ( 50 GB ) and one reader process
CFQ 78849 KBps
Deadline 79203 KBps
Centos 5.2 , iosched/fifobatch set to 1 .
| | |
| |
| 2.32, rstone (??), 11:27, 10/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>SSDSA2SH064G1GC ( X25E , Kingston OEM , 64G ) ,
>FW 8790
>RANDOM READ TESTS .
record size = 50 kb , ( специфика нашей аппликации )
| | |
| 2.33, aospan (?), 12:18, 10/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Похоже не быстро даже для "record size = 50 kb", хотя x25e вроде как более "продвинутый" относительно x25m. По моим графикам при таком размере блока скорость "random read" около 120 МБ/сек.
Поглядите, может NCQ отключен (dmesg | grep NCQ) ? Без NCQ скорость чтения заметно падает ( наблюдаю падение с 250 МБ/сек до 180 МБ/сек т.е. примерно -30% ).
| | |
|
| 1.37, edo (ok), 10:08, 12/01/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
я неправильно читаю график или действительно для блоков размером менее 128кб/с random write намного быстре sequential write?
| | |
| |
| 2.38, aospan (?), 12:35, 12/01/2010 [^] [^^] [^^^] [ответить]
| +/– | |
да, так и есть. объясняется это скорее всего тем, что при записи контроллер может писать только блоками по 128 КБ (или более). При этом при последовательной записи если в блоке уже есть данные, то контроллеру необходимо их считать, добавить к ним новые данные и записать обратно.
При рандомной записи таких ситуаций возникает меньше т.к. есть вероятность, что часть данных будет записана в блок размером 128КБ один раз.
| | |
|
|
