Между SMP и многоядерностью / мульти-CCX (годится как аналогия) — очень большая разница. Дъявол кроется именно в деталях реализации. Одно дело когда мы навесными средствами пытаемся два независимых адаптера заставить работать над одной картинкой, и совершенно другое, когда два набора вычислительных ядер объединены логически и имеют общие части управления, общие кеши, общую память, и т.п.
А вот да, кто придумал слот M.2 размещать между процом и первым широким слотом PCIe — это просто гений. Ему надо выдать премию за одно из самых невменяемых инженерных решений.
Не, я не о том. Я о том, что прирост до QD=4 должен таки сохраниться из-за распараллеливания по банкам, префетча и переупорядочивания. Если его не будет вообще — это хлам, а не накопитель.
SATA-vs-NVMe есть некоторая разница.
-
У меня есть и такое, и такое. Сначала не хотел брать отдельный системный NVMe накопитель, но когда попробовал — понял, что разница таки есть, и она похоже не вот что в линейных скоростях чтения-записи, а скорее в IOPS. Поигрулькам допустим пофиг. А вот на первичный старт системы влияет сильно.
-
Ну и разница в линейной скорости тоже заметна, только на специфике — на уходе в спячку на диск («гибернации»). На SATA и хорошем NVMe время сброса 12-32 гигов на диск и загрузки их обратно различается достаточно сильно :) Одно дело 500MB/s, когда ты сброса-восстановления 16 гигов ждёшь полминуты, а 32 — минуту. Другое дело 3000, когда это 5-10 секунд :D
Ну как давно, есть тут под рукой пара ноутбуков с HDD.
Да терпимо, если кроме браузера и просмотрщика видео ничем не пользоваться.
(пользователи «за 60»)
Некоторые скоростные радиорелейки в этих частотах работают, насколько помню (возможная полоска 3.3-3.9). Вряд ли это «последняя миля». Это скорее канальчики до отдалённых населённых пунктов. Хотя хз, может я что-то пропустил.
Да а что толку от Queue Depth, если там пристойного буфера, чтобы оптимизировать операции, нема?
По сути либо линеаризованные операции, либо очень близко к тому. Понятно, что хотят максимально упростить контроллер.
В таком раскладе QD>1 может даже ухудшить, драйверы не очень любят короткую очередь ныне. Но я поставлю на эффект от QD где-то до 4, небольшой буфер и небольшая очередь там всё равно быть должны, если они не совсем в хлам решили линейку превратить.
Да не, на левелинг это сильно влиять не должно.
А вот на производительность — например при работе внутреннего переупорядочивания блоков запись будет проседать, да. Возможно и линейное чтение тоже, потому что почти наверняка в моделях с большим буфером есть префетч.
Именно что чудесным — контроллер примет блоки в очередь, и сразу же ack'нет передачу. Далее в фоне переупорядочит запись набора блоков так, как ему удобно, и как заложено в микропрограмму. После чего в фоне отпишет блоки, и уже по мере реальной записи выдаст подтверждение на элементы длинной очереди записи. При этом в очередь за это время может ещё набежать без особых проблем, и читать вы можете в это время с устройства без особых проблем — только контроллер знает, пересекается ли ваше чтение с записываемым банком (можно ли читать параллельно).
-
В случае же прямой передачи команд контроллеру без буферизации вы будете ждать подтверждения на передачу и запись вместе, потому что буфера нема. В лучшем случае каждой пары мегабайт, если там всё-таки какая-то небольшая очередь будет иметься. В худшем — каждого блока независимо от размера, полностью сериализуя доступ и делая невозможными асинхронные операции чтения.
-
А если флешу понадобится сделать длинное по меркам системы внутреннее переупорядочивание или поTRIM'аться в фоне — то ваша запись начнёт вставать колом и дополнительно ждать завершения внутренних операций. Хотя в случае наличия большого буфера, вполне вероятно, что поместилась бы в него, и наличия этих внутренних операций вы бы даже не заметили.
-
Ближайший схожий пример — харды с NCQ и без NCQ (если кто помнит).
-
Ну и есть ещё один момент. Буфер DRAM нужен ещё для того, чтобы не лазить постоянно в флеш за таблицей блоков, которая сопоставляет логические блоки, видимые системе, и физическое их размещение в флеше. Это не вот бог весть какие накладные расходы, но при рандомном чтении может быть заметно.
-
Короче скорее всего хреновые показатели «убюджетненного» 980 в приличной мере всем вышеописанным (сиречь отсутствием приличного буфера) и будут объясняться. Хороший способ убить хороший флеш :D
Я кстати перечитал новость, и снова не могу определиться — это таки плохо или хорошо.
Очень похоже на прицельное попадание в собственную же ногу, образно.
-
У меня есть и такое, и такое. Сначала не хотел брать отдельный системный NVMe накопитель, но когда попробовал — понял, что разница таки есть, и она похоже не вот что в линейных скоростях чтения-записи, а скорее в IOPS. Поигрулькам допустим пофиг. А вот на первичный старт системы влияет сильно.
-
Ну и разница в линейной скорости тоже заметна, только на специфике — на уходе в спячку на диск («гибернации»). На SATA и хорошем NVMe время сброса 12-32 гигов на диск и загрузки их обратно различается достаточно сильно :) Одно дело 500MB/s, когда ты сброса-восстановления 16 гигов ждёшь полминуты, а 32 — минуту. Другое дело 3000, когда это 5-10 секунд :D
Да терпимо, если кроме браузера и просмотрщика видео ничем не пользоваться.
(пользователи «за 60»)
По сути либо линеаризованные операции, либо очень близко к тому. Понятно, что хотят максимально упростить контроллер.
В таком раскладе QD>1 может даже ухудшить, драйверы не очень любят короткую очередь ныне. Но я поставлю на эффект от QD где-то до 4, небольшой буфер и небольшая очередь там всё равно быть должны, если они не совсем в хлам решили линейку превратить.
А возможно даже и просто HDD. Браузеры с одноглазниками ныне особо по диску не шарят.
А вот на производительность — например при работе внутреннего переупорядочивания блоков запись будет проседать, да. Возможно и линейное чтение тоже, потому что почти наверняка в моделях с большим буфером есть префетч.
-
В случае же прямой передачи команд контроллеру без буферизации вы будете ждать подтверждения на передачу и запись вместе, потому что буфера нема. В лучшем случае каждой пары мегабайт, если там всё-таки какая-то небольшая очередь будет иметься. В худшем — каждого блока независимо от размера, полностью сериализуя доступ и делая невозможными асинхронные операции чтения.
-
А если флешу понадобится сделать длинное по меркам системы внутреннее переупорядочивание или поTRIM'аться в фоне — то ваша запись начнёт вставать колом и дополнительно ждать завершения внутренних операций. Хотя в случае наличия большого буфера, вполне вероятно, что поместилась бы в него, и наличия этих внутренних операций вы бы даже не заметили.
-
Ближайший схожий пример — харды с NCQ и без NCQ (если кто помнит).
-
Ну и есть ещё один момент. Буфер DRAM нужен ещё для того, чтобы не лазить постоянно в флеш за таблицей блоков, которая сопоставляет логические блоки, видимые системе, и физическое их размещение в флеше. Это не вот бог весть какие накладные расходы, но при рандомном чтении может быть заметно.
-
Короче скорее всего хреновые показатели «убюджетненного» 980 в приличной мере всем вышеописанным (сиречь отсутствием приличного буфера) и будут объясняться. Хороший способ убить хороший флеш :D
Впрочем, эти места обычно покидаются достаточно быстро.
Очень похоже на прицельное попадание в собственную же ногу, образно.