Автор не входит в состав редакции iXBT.com (подробнее »)
avatar
и давно у сигада появились 2.5" со встроенным usb? не припоминаю таких. у wd/tohiba — да, есть, но и там стоит внешний usb-sata, мост, просто перенесенный на плату контроллера винта, подпаятся перед которым напрямую к sata дело нехитрое.
avatar
лучше, конечно, перебором не заниматься, а посмотреть на версию прошивки и сразу сделать правильный вывод. процентах в 90 накопителей они имеют характерный вид.
в остальном же… фисонские (и sata и nvme) наверное в конец списка — там много всего читается и иногда может завесить. остальное исходя из подозрений.
спасибо, так ведь будет стоять на полочке и радовать глаз. обидно же…
avatar
надеятся, что ваши проблемы связанные с некомпетентностью решит какой-то левый дядя забесплатно — не стоит. если кто-то этим и займется — только за счет покупателей. и тех кому эта «помощь» нафиг не нужна — тоже.
ну а вообще — «жизнь несправедлива». пора бы уже понять.
avatar
это у флешек первые N секторов можно писать-читать, а после них — данные уходят в никуда. да и тут вообщем-то лучше заняться дихотомией, а не случайным поливом.
у рилтековских (а других контроллеров ssd позволяющих сделать липовый обьем на данный момент неизвестно) ssd никакой привязки к секторам нет, критичен только суммарный записанный обьем. а в данном тесте он мизерный и за пределы возможного не выйдет.
p.s. если напускать на флешки h2t с частичным указанным обьемом — это надо гонять сразу после форматирования. драйвера как минимум всякого fat'а под виндой занимаются «выравниванием износа», и если сначала погонять тесты — то следующие (тестовые h2t*) файлы окажутся после файлов созданных при тестировании, несмотря на то что они уже удалены, соответственно живой обьем будет занижен. а до самого начала дело дойдет только после записи до конца раздела (а при частичном обьеме — не дойдет). это возможная причина расхождений здесь.
avatar
Настоятельно рекомендую скачать утилиту ValiDrive с сайта автора и обязательно проверять ей любые безымянные накопители.

с (настоящими) ssd на рилтеках с липовым обьемом он недееспособен.
avatar
да какие 5, «флешки сони» на необьятные тогда еще гигабайты — это тема наверное из нулевых еще.
avatar
это вопрос времени и количества. винты дохнут совершенно независимо от производителя.
выбор бренда исходя из подобного критерия (собственного опыта на незначительно количестве дисков) — не более чем самообман.
avatar
«отстающие» конкуренты уже не первый год продают винты с другими вариантами earm. так что оставал тут только сигад. хотя с точки зрения потребителя таковое отставание было скорее к лучшему.
avatar
на коробке — 2402, сам ssd — 2311
avatar
типовая флешка на jms901+ufs. основные вопросы к ней — размер сектора (бывает 4к), поддержка трим (бывает не всегда), ну и скорость записи тоже падает, но обычно не сильно. а вот проблем с обьемом не припоминаю. накойхрен гонять на ней cdm одному автору известно. наверное цифры красивые.
avatar
smi вечно опаздывают. видимо собираются и в очередной раз повторить.
avatar
а наш «малыш» совсем обделён природой — 860/460 МБ/с.

очевидно оставили лазейку для совсем уж утлого двухканальника, 63xt с парой каналов действительно может не вывезти гиг чтения. но пока таких неликвидов не нашли.
avatar
толку с этого корпуса, когда с ним нет теплового контакта. был бы — не перегревалось бы.
avatar
если 970evo потребляет сотни мВт — значит он не спит. и это вопрос уже не к нему, а настройкам системы.
avatar
в legend 860/500g нынче встречается ровно тот же конфиг.
avatar
в прошивках без прямой записи все гораздо хуже и никаких восстановлений.
avatar
помнится, голая платка от dtmaxA была где-то на грани. но правда там чтение gen2, а запись всего ~400.
ее прижим на пластик корпуса через термопрокладки создал легкий запас.
avatar
Это указывает на малый объем кэша и медленную память.

вот как раз это все указывает на перегрев.
толи внутри просто нет контакта контроллера с корпусом, толи мелкий корпус не справляется с рассеиванием тепла.
avatar
так не берите. остальным до этого какое дело и интерес?
avatar
время стирания блока на пару порядков ниже, чем время записи всех страниц блока. и от режима практически не зависит. так что стирание оказывает гомеопатическое влияние на перезапись.
медленная именно запись в 4хбитном режиме.
у утлых саташных безбуферников видимо еще и с распараллеливанием этого процесса плохо, возможно набортной памяти не хватает. по всяком случае полноценные 2258/9+dram обгоняют на записи с уплотнением себя же в безбуферном варианте раз в несколько.