Как стать автором
Обновить

Комментарии 68

НЛО прилетело и опубликовало эту надпись здесь
Ну раз греется, чего бы мелкий радиатор в комплект не вложить? Кому действительно место позволяет приклеили бы.
НЛО прилетело и опубликовало эту надпись здесь
А эти платы-переходники отдельно купить можно?
Например на Али? Какую взять?
А есть что-нибудь такое же шустрое, но объемом 60-120 гигов?
НЛО прилетело и опубликовало эту надпись здесь
В плане операционных систем требования простые: [...] MacOS High Sierra (10.13)

Да, требование иметь ОС, которая ещё не вышла, — это простое требование, точно. :)
В пределах ассортимента кингстона безумно рад за ребят… но до годовалого 960 pro как до Луны пешком в любых тестах при той же цене… так что простите, но нет.
960 Evo 256 Гб — цена 9к. При том засунутый в ноутбук не поднимает температуры выше 50-60 градусов, как ни старался (i7 & 1050ti по соседству не помешали).
Так это Evo, там TLC, в отличие от Pro, в котором MLC память. А Pro у меня тоже не греется выше 60. Правда, он у меня не в ноуте.
Почему контроллер от Phison, а не Silicon Motion?
Patriot hellfire M2 pcie 3000 чтение 2100 запись первые 32 гигабайта.

аналогичный контроллер аналогичный — PS5007-E7
обьем такой же
аналогичные тесты — ваш тормозит на 6-20 процентов особенно на глубоких очередях. какой тип памяти у вас? у хелфайра старая добрая надежная MLC с отличным ресурсом
Почему ваш хуже по производительности? Может нужно чтото в прошивке поправить… первые хелфайры тоже тупили на малых очередях но потом вышло обновление прошивки и вуаля — полетел раза в полтора быстрее… сейчас ваш продукт явно какой-то переходный — вроде лучше первой прошивки но явно хуже второй. Ну и нагрев… ещё один производитель который забил болта на перегрев. ну что тяжело пластинку алюминия положить в комплект? или хотябы не закрывать наклейкой чип чтоб я сам прилепил радиатор? срыв стикера с чипа — прощай гарантия так же?
НЛО прилетело и опубликовало эту надпись здесь
если проц таки действительно phison то по даташиту на него же ему надо радиатор и не менее 8 кв см эквивалентной площади рассеяния. и как можно догадаться радиатор не через этикетку надо к чипу прислонять а напрямую через термопасту. он имеет пиково до 10 ватт выделения тепла! он потому и тротлит на записях или чтениях — нагревается до 90 градусов и тротлит чтоб не сгореть! Это нарушение предписаний производителя. в случае с хелфайром все обззорщики заплевывали производителя т.к. не обеспечил должного охлаждения и по сути — запретил доработку системы охлаждения извне. тут поступили точно так же! Чем вы думаете господа? Вы правда уверены что если Ваши ссд будут дохнуть от перегрева через год-два — ктото пойдёт ещё покупать ваши недоделанные устройства? Или надеетесь продавать откровенный контрафакт отказывая в гарантийке по причине поврежденной этикетки?

У Этого кингстона этикетка — просто стикер. нет никакой там медной основы. А если б и была — какова площадь этой основы? нижнюю часть этикетки в расчет нельзя брать — она к гарячим микрухам памяти прилеплена. так что остается мелкое пятнышко сверху. что оно может рассеять? Неужто так сложно было наклеить этикетку на другую сторону диска?
НЛО прилетело и опубликовало эту надпись здесь
1) в смартфонах тупо экономия т.к. вместо тепловой трубки просто приводят самоклейкую медную фольгу несколько бОльшей толщины и все. в лучшем случае — алюминевый корпус подведут лепестком под проц.

2) Даже наклейка радиатора через терможвачку на бирку уже облегчает на 20 градусов температуру простоя но снова таки стоит дать газу как температура снова улетает за 90. только радиатор и обдув вентилятором позволяет нормально работать. это происходит потому что радиатор может работать эффективно когда он сам до 60 градусов прогреется а он этого сделать не может. изза переходных пластин между температурой кристалла и температурой радиатора есть зазор градусов в 40 — вот и получается что на радиаторе 40 а на проце уже 80-90. обдув радиатор до 20-ти — получим на проце 70-80 — уже можно жить. но чтоб удержать маленькую пластинку алюминия глубоко в системнике в такой температуре — надо хорошо продумать откуда вентилятор воздух будет брать и куда будет уходить гарячий.
Чуть больше года назад взял Samsung 950 PRO MZ-V5P256BW.
Сразу после покупки этот NVMe PCIe показывал чудеса производительности, сейчас выдает примерно 75% от того что было.
Температура при минимальной нагрузке — не ниже 55 градусов.
Установлен так же, как и на показанной выше картинке (корпус алюминиевый, охлаждение хорошее).
Реальная производительность:
рядом стоит Surface 4 Pro, внутри которого стоит такой же самсунг.
Скорость загрузки ОС Вин 10 у сюрфейса в 5 раз (!) выше, чем у десктопа (i7-6700), и это при том, что у десктопа в 4 раза больше памяти, а на Surface включен битлокер.
(основной набор софта на этих двух компьютерах одинаковый)

Вывод: мало иметь быстрый NVMe PCIe — надо иметь еще и оптимизированную под его использование аппаратную часть — иначе разницы с SATA SSD можно и не заметить.

Мне кажется, скорость загрузки Surface обеспечивает именно что TPM: в его железо нельзя вмешаться, всё зашито/защищено, и пока система считает, что всё ок — использует самые быстрые алгоритмы загрузки. А уж если загрузка не прошла — будет полный цикл инициализации. Samsung такое уже делал в 900-series буках, если мне память не изменяет.
Я, после того как оставил сообщение здесь — прогнал тесты на этих двух компьютерах.

Надо признать — я ошибся, в Surface стоит похожий, но другой самсунговский PCIe SSD на 256 Гб.
Результаты вообще шокировали — сюрфейсный MZFLV256, по тестам, минимум вдвое медленнее Samsung 950 PRO.
А система (не только при загрузке) работает быстрее* (пока не упирается в меньшее количество памяти).

*на обычных офисных задачах.


Ну а по части задач… Тут, видимо, играет роль вылизанный набор драйверов, которые контролировали сами майки. Имиджевый продукт, как-никак. Имхо. Надо гуглить и изучать тему.
А у Вас, извиняюсь, сколько на нем свободного места? У SSD обычно деградирует скорость по мере уменьшения % свободного места на диске. Тот же Samsung даже over-provisioning предлагает в своей утилите.
«расположение разъёмов на материнских платах заставляет усомниться в адекватности инженеров, придумавших эту фичу»

На новых платах ASUS предусмотрена вертикальная установка SSD M.2
Очевидно — именно для того, что бы улучшить охлаждение.
у M.2 формфактора в связи с нагревом есть еще одна беда — при нагреве их выгибает (плата же расширяется), и отрывает пятаки под чипами. Пример весьма свежих ссд, падёж массовый:
image
И это не при отпайке оторвали, чип подымался по всем правилам.
А что там с базами данных? Почему его нельзя пользовать для баз то?
Потому что не рассчитан на серверные нагрузки. Прошивка контроллера отличается, резервная зона, ресурс ячеек. Серверные не просто так дороже (и ощутимо дороже). Железо там совсем другого уровня
И там нормальная SLC память.
А кингстон да же в пределах одной статьи сам себе противоречит:

Для рабочих станций тоже сгодится, но не под базы данных и всё такое. Игры, обработка фото, работа с видео — эт его стихия, да.
Программисты, работающие со сборкой софта или огромными БД будут в восторге.
Ну одно дело — прогерские запросы при работе с БД: написать выборки, проверить, оттестировать. Тут и скорость работы вырастет, и по ресурсу не сильно бьёт. И уж совсем другое — использовать такие накопители именно как постоянное хранилище высоконагруженной (особенно на запись) БД на проекте, не? Для каждой железки — свой рынок и свои пользователи.
«И там нормальная SLC память»

Серия KC400 позиционируется как серверная. А там MLC.
Как и у множества других серверных SSD.
Используйте на здоровье, разве Вам кто-то запрещает? Но если нагрузка на базу большая, то так аккуратно упоминаемый в статье перегрев может оказаться серьезной проблемой. Да и про ресурс перезаписи забывать не стоит.
Самое главное — отсутствие защиты целостности данных при аварийном отключении питания. В большинстве SSD используется RAM-кэш, в том числе на запись (нужно объединить мелкие блоки перед записью, временно хранить данные при сборке мусора и т.д.). В общем, ситуация похожа на write-back в RAID контроллерах.
Играюсь с kingstone'ами в лаборатории.

Примерно №2-№3 в топе (и это, пардон, с учётом DC-grade железок), так что ощущения очень приятные.

Но у меня есть один вопрос, который я задаю всем вендорам, и никто не хочет отвечать. Почему на SSD, в т.ч. в NVME формате, такая ужасная пиковая latency?

Вот результаты моего бенчмарка для KINGSTON SEDC1000H800G (iodepth=1, randwrite=100%, span=80%, blocksize=4k)
avg = 502 us
99.9% < 1450 us
max = 8379000 us

8 секунд! Воспроизводимо. На графике выглядят как периодические супервысокие всплески.

Уточню, проблема характерна для всех SSD устройств, а не только для kingston'ов.
У SSD дисков latency на запись очень неровная. Связано это с их внутренним устройством (когда за раз записывается блок большого размера, при необходимости, перемещая и перенося данные с места на место). Чем больше этот блок, тем сильнее пики latency (то есть сиюминутные провалы в производительности). У обычных магнитных дисков графики совсем другие — они напоминают ровную линию практически без отклонений. В случае линейного последовательного IO эта линия проходит высоко, в случае постоянного случайного IO — постоянно низко, но, ключевое — постоянно. Latency у жёстких дисков предсказуема, latency у SSD — нет. Заметим, это свойство есть у всех дисков. У самых дорогих latency оказывается смещена (либо очень быстро, либо очень-очень быстро) — но разнобой всё равно сохраняется.

Отсюда. Насколько я понял, это не только к RAID относится.
Короче: похоже, что SSD при записи двигает уже записанные данные по диску, чтобы влезли новые.
Спасибо за ссылку на мой собственный пост. С тех пор меня эта проблема (пиковых задержек) интересует всё сильнее и сильнее.
почитайте про технологию работы с flash памятью. внимательно почитайте!
Ключевой момент — Дописывать можно, перезаписывать НЕЛЬЗЯ!
У любой ячейки флеш памяти ограничено именно кол-во стираний так как оно происходит долго и высоким потенциалом. стирание делает ячейки равными единицами — тоесть заряжается затвор. записывая данные мы разряжаем затвор прописывая ноль а где надо оставить единицу — оставляем. Фишка в том что стирается только огромный блок целиком. а дописывать можно хоть побайтово. потому когда ты начинаеш дописывать мелкими кусочками то контроллер старается каждый кусочек кидать в новый чистый предварительно стертый блок. Но кол-во этих блоков ограничено и когда они все израсходуются на мелкие кусочки файла — контроллеру прийдётся прочитать штук 100-200 таких блоков, собрать воедино кусочки разрозненных данных и записать один огромный полный блок полностью а остальные — постирать. в это время ты смотриш на ланетси и удивляешся шо ж такое чо он там делает только что микросекунды были а сичас секунду тупил. а вот так. выходом из этой хрени есть SLC режим. когда некое поле ячеек всегда после чтения стирается автоматом. не знаю как у указанного ssd в статье а вот у patriot hellfire этот кэш составляет 32 гигабайта. вот первые 32 гига туда залетают просто наура безо всяких задержек. но когда кончается этот кэш и кончается оперативка — начинается рекомбинация полупустых блоков с добавлением до полного блока в основной массив памяти и освобождение кэша. помере высвобождения SLC кэш снова освобождается и новая порция данных может туда загудеть.

Поэтому правило очень простое. оставляйте не менее половины свободного места на ssd винте. а лучше 2/3. тогда во время простоя проц сам рекомбенирует блоки в большие а остальные блоки будут свободны для мгновенной записи любого обьема данных последовательно или максимально возможного кол-ва дозаписей микроскопических кусочков данных.

Вы должны понимать что когда вы дописываете к файлику в 200 байт ещё два байта то чтоб они сохранились на ssd — контроллеру приходится весь этот сектор прочитать (512 байт) потом изменить его содержимое дорисовав эти два байта, а потом найти свободный чистый блок на 4 килобайта(обычно такой размер блока у ссд но бывают и больше и меньше) если нашел — быстренько прописал и вернулся за старым — стереть его. тоесть в таблице старый уже помечен как пустой но он ещё не чистый — процедуру стирания ему не проводили. если в этот момент прилетит ещё чтото то блок стерт не будет и так накопятся нестертые блоки. в конце концов дописывая ещё пару байт к 300 байтному файлу вам прийдётся ждать чтения данных, изменения двух байт, поиска пустого блока — опа нету, опять чтения ещё пару тройки полупустых блоков, их комбинация воедино, стирание одного из блоков, прописывание старых данных из предыдущих трех, потом стирание ещё двух блоков опустошенных и только тогда в один из них пропишется ваш измененный файлик. и да. одна пластина памяти может только один блок за раз стереть или одну огромную страницу. потому они стараются в одну микруху напихать побольше пластин а производители дисков — напихать побольше микросхем. чтоб можно было стирать блоки в как можно большее кол-во рук. увы это особенности современной технологии флеш памяти. якобы только 3дхпоинт интеловская не такая но я её в руках не держал и она слишком дорога и малого обьема пока что.
Я так понимаю SLC это аппаратный аналог TRIM-а для ОС. Если при использовании TRIM ОС отвечает за отдачу команд на стирание блоков и поддержания нужного объема чистой памяти, то при SLC это делает контроллер?
Нет. SLC (single level cell) — тип ячеек. В чистом виде сейчас его никто почти не использует. Производительность и ресурс большие, но и плотность хранения ниже. В некоторых SSD на базе MLC/TLC есть SLC-кэш — небольшая часть общего объёма NAND работает в SLC режиме в качестве кэша.
«аппаратный аналог TRIM-а для ОС» — то, что Вы пытаетесь описать называется сборкой мусора и есть в любом SSD.
неа. Никак не аналог вообще. SLC это именно кэш быстростираемой памяти которую контролер всегда старается держать чистой и готовой к тоннам записи.
Трим дает контроллеру понять какие блоки данных больше не нужны чтоб пометить их на стирание. SLC кеширование — это по сути измененный принцип работы самой флешпамяти.
к файлику в 200 байт ещё два байта то чтоб они сохранились на ssd — контроллеру приходится весь этот сектор прочитать (512 байт) потом изменить его содержимое дорисовав эти два байта

Записать 200 0xff а потом те два байта, не пойдет?
ну чесно говоря да. пример не особо. операционка оперирует секторами в 512 байт а ssd может стереть минимум один блок 4 килобайта. и если блок начался с начала файла и потом файл не модифицируя дописывается то такая операция действительно происходит сверхбыстро просто дописываясь. но всеравно если следующим сектором в блоке будет левый файл то естественно контроллеру при модификации первого файла рано или поздно(когда допишется следующий сектор файлу) прийдется найти новый стертый блок под этот файл скопировав весь блок в новый.

Изза этих перестроений по пустякам у прошивок есть такое понятие как коэффициент усиления записи. тоесть пишеш ты 1 гигабайт последовательно — ячейки испытают ровно 1 гигабайт записанных данных износа. но стоит записать 100 мегабайт мелких файлов или 100500 кусочков дописывать(работа с базами данных многофайловых систем) то 1 гигабайт реально дописанных данных может вылиться чуть ли не в два гигабайта реального износа ячеек изза перегруппировок кусков файлов в новые блоки. но в среднем у хороших прошивок — коэффициент этот 1.2-1.5. Вот такое вот дело. Но в общем Phison этот показывает достаточно крутую производительность. главная пролема — на него пока совсем нет нормальных прошивок. ну и аппаратно он имеет немного считающуюся устаревшей технологию восстановления битых данных. Но она всеравно достаточно неплохо работает а главное — очень быстро. плюсом он 4ядерный :) а нормально сделать распаралеливание однопоточной команды это знаетели нетривиальная задача. Но в данный момент например вторая прошивка — вполне себе ничего. они в ней очень кардинально все поменяли хоть и минуснули целых 80 гигов на кэш системные нужны и подменный фонд. 428 гиг доступно из 512 :)
ssd может стереть минимум один блок 4 килобайта

Практика еще хуже — erase работает над блоком (128, 256 или 512 КБайт), который состоит из 32, 64 или 128 страниц по 2-4 КБ: https://flashdba.com/2014/06/20/understanding-flash-blocks-pages-and-program-erases/
Each block contains a number of pages, which are the smallest unit that can be programmed (i.e. written to).
The important bit here is that program operations (i.e. writes) take place to a page, which might typically be 8-16KB in size, while erase operations take place to a block, which might be 4-8MB in size. Since a block needs to be erased before it can be programmed again ..., all of the pages in a block need to be candidates for erasure before this can happen.


Запись в стертый блок ведется страницами (2 или 4 КБ).

Ну помоему это справедливо только для 3dVNand но принцип да — тот же. стирать можно только огромный кусок данных а потом уже писать в него. Насколько я смог заметить у хелфайра минимальная стираемая единица именно 4 килобайта страница. хз как это — аппаратно или програмно через slc кэш они реализовали. Но даже с таким гигантским кол-вом diу — 4 микрухи по 8 в каждой — всеравно конец приходит быстро :)

Нет, схема адресации, программирования и стирания страница — блоки — плоскости — чип одинакова для всех NAND флеш чипов и для всех NAND протоколов.
Записывают данные в стертые страницы постранично, стирают блоки из 64-128 страниц.
Patriot Hellfire M.2 480GB построен на PS5007-E7 и Toshiba 15nm MLC, TH58TFT00FLBA8H, кристаллы "флеш-памяти c интерфейсом Toggle Mode и ёмкостью по 128 Гбит"


Для чуть более старого Toggle NAND от тошибы есть даташит — http://www.datasheetspdf.com/PDF/TH58TEG8DDKTAK0/910996/10 — размер страницы 17664 байт (16КБ+1380 байт), размер блока 4МБ + 320 КБ (256 страниц). Списки операций — программирование страницы, стирание блока: "Basic Operation:… Page Read Operation… Page Program Operation… Block Erase Operation… Multi Block Erase Operation"
"SLC кэш" — это запись в страницы блока через одну (для MLC) или через две (для TLC)

О! вот об этом я и догадывался.ведь реально ж через 32 гига в нем чтото кончается и начинается тупеж. Спасибо за даташит на микрухи памяти. — это 100% инфа что там они — просто у меня 250 гиговая версия и все микры этикеткой перекрыты.
Высокие пиковые значения есть у всех, но «высота» разная. У SSD здорового человека — порядка десятков мс при на запись с qd=1. А в десктопных на это внимания никто не обращает — подвисла там одна из 1000 (миллиона, миллиарда?) IO на сотни или даже тысячи мс — это можно пережить и даже не заметить.
Нет устройств с пиками в десятки милисекунд. Лучшее, что у меня есть в списке — 2600 мс (2.6 секунды).

Разумеется, с qd=1. Мне потребовалось несколько месяцев пустых бенчмарков, пока я не обнаружил, что на span=40Gb проблема просто не обнаруживалась. Теперь — 80% span, обязательно.
Нет устройств с пиками в десятки милисекунд.

Toshiba PX02SM и PX03SN: 12,74 мс и 18,77 мс соответственно. Preconditioning был.
Если что-нибудь посовременнее, то вот HGST SN150:
«clat»: {
«min»: 1,
«max»: 239,
«mean»: 21.52,
«stddev»: 3.65,
«percentile»: {
«1.000000»: 19,
«5.000000»: 20,
«10.000000»: 20,
«20.000000»: 20,
«30.000000»: 20,
«40.000000»: 20,
«50.000000»: 20,
«60.000000»: 20,
«70.000000»: 21,
«80.000000»: 21,
«90.000000»: 25,
«95.000000»: 30,
«99.000000»: 36,
«99.500000»: 37,
«99.900000»: 44,
«99.950000»: 45,
«99.990000»: 54,
«0.00»: 0,
«0.00»: 0,
«0.00»: 0
}
Безобразно себя вели в этом плане лишь OCZ, большая часть из т.н. read intencive SSD и десктопные — но к ним претензии предъявлять не стоит.
P.S. Вывод FIO — в микросекундах
А, я понял.

Я забыл указать, что в бенчмарке обязательно надо:
а) Бенчмаркать не голое устройство а файловую систему (файл на файловой системе)
б) Указать fsync=1

Примерно половина устройств, которая себя вела хорошо в отсутствие fsync'а превращалась в унылое «г» в режиме с fsync=1.

Какая именно файловая система — не важно, можно xfs или ext4. Драматичные задержки возникают из-за отправки flush'ей из блочного уровня после каждой операции.
Указать fsync=1

аа, так это совсем другое дело.
Да, прошу прощения. У меня в голове дискуссия с вендором, и я путаю что я кому говорил уже, а что кому нет.

Наиболее боевой нагрузкой на диски является OLTP (базы данных) и ceph. Т.к. ceph при этом ещё и выступает в роли обычного хранилища, то итоговая нагрузка получается больше, потому что на каждую запись он делает один flush. Мой стандартный бенчмарк подразумевает ceph-all-in-one с одним диском в качестве OSD. Итоговую цифру IOPS на запись можно умножать на два, а latency — делить на два.

И в этих условиях десятки секунд показывают практически все вендоры.
Вот меня интересует не система на таком диске, а использование его в качестве кеша для HDD.
Есть фирменные утилиты для этого? У меня материнка поддерживает Intel Rapid, но в Win10 он не работает.
Это странно. На сайте intel есть драйвер для Win10 и на их форуме пишут, что всё работает.

Говорят, что может не работать по таким причинам и лечится таким образом:
superuser.com/questions/546601/no-accelerate-button-tab-on-intel-rapid-storage-window
(Кратко: уже размечен диск, либо включен hot-plug)
не работает, ни с одним официальным драйвером, а после большого обновления 10ки — intel rapid вообще перестал запускаться — точнее вылетает с ошибкой. При загрузке на экране показывается raid 0 из hdd и раздела SSD для cache, но статус у него disabled.
Стоит попробовать пересобрать заново этот рейд. И удалить раздел с SSD.
Сказано что он только для десктопов, или рабочих станций, но не для баз данных. А подскажите, криптовалюты с их тяжелыми кошельками к чему относятся? Ну к примеру, когда эфировский Mist запускаю, то вижу что память, процессор и ssd загружены на полную катушку. Диспетчер задач показывает скорость обмена на ssd в 380мб\с, в то время как грузятся блоки. А это долгий процесс, очень долгий. Ну и другие крипты ведут себя похожим образом. Вот это к чему отнести надо, к домашним или к серверным нагрузкам? Какой серии брать SSD? Ну и важен вопрос, сколько данные продержаться, если эта планка без питания в укромном месте лежать будет.
На чтение большинство устройств довольно быстро. Сильнее всего разница на записи.
Причем тут чтение? Вы загрузите этот кошелёк и увидите что там постоянная перезапись чего-то с бешеной скорость идёт. Если бы было только чтение, я бы и не парился, тут ясное дело, любой подойдёт.
Тогда стоит посмотреть на паттерн записи. Как часто оно делает fsync? Пишет оно большими или мелкими блоками?

Происходящее можно посмотреть с помощью blktrace. Там будет много, так что 1-2 секунд записи в момент высокой нагрузки будет достаточно.
Первое, что требуется для загрузки с NVMe — наличие UEFI, а его в GA-P55A-UD5 видимо нет.
Да, UEFI нет. Спасибо за ответ. Я примерно так и думал, но мало ли, может диск может как-то прикинуться sata для загрузки, а потом уже работать через драйвера системы.

Никто не мешает грузить загрузчик с SATA диска.

Там ещё и PCI Express 2.0, а диск хочет 3.0, так что и со скоростями будет «не то».
«А у Вас, извиняюсь, сколько на нем свободного места?»

На десктопе — 93 из 237
На Surface — свободно ровно 10%, тем не менее — он работает быстрее, несмотря на тесты.

Я сталкивался с подобным на старом Макбук Про (2009) г.в. (с SSD, up.) — родная OSX на нем летала, Win 7 в буткампе работала заметно медленней (что было особенно заметно по видео).
Что интересно — сейчас там стоит 10 и Sierra, и ситуация изменилась на противоположную.

Ничем иным, как оптимизацией драйверов это не объяснить.


Зарегистрируйтесь на Хабре, чтобы оставить комментарий