После
неудачи с hp x911s был выбран более вероятный экземпляр флешки на phison u17 в виде продукции silicon power. Кандидатов было несколько — ms60,ms70,ds72,m80, этот на момент покупки оказался самым дешевым. Мелкая полезность — она в отличие от перечисленных оснащена парой разьемов, A+C.
У silicon power есть на данный момент 4(?) накопителя на данной аппаратной базе. Впрочем в спецификациях не указано, и вполне вероятно со временем внутри может оказаться что-то иное. Один из них позиционируется как флешка (Marvel Xtreme M80) в достаточно распространенном для SP корпусе, остальные как внешний ssd, с одинаковым более крупным корпусом.
MS60 имеют сравнительно низкие заявленные скорости (600/500MB/s).
для M80 на сайте сейчас заявлены 1000/700-800, но интернет хранит снимки упаковки, где указаны ~600/250-500. Видимо спецификации уже менялись.
MS70 и DS72 — около потолка usb3/gen2 (1050/850MB/s).
Т.е. по идее DS72 это старшая модель, и почему она оказалась дешевле остальных непонятно.
За время написания обзора этот вопрос разрешился — цена взлетела почти вдвое, и одновременно закончилась.
Phison предлагает два родственных контроллера — u17 и u18. Второй отличается поддержкой gen2x2 и удвоенными максимальными скоростями. Моделей на u18 у SP на сегодня не замечено.
Поставляется данные модели от SP в запаянном одноразовом блистере.
Конструкция своеобразная, среднеразмерный корпус из крашеного металлического трубчатого профиля с двумя несьемными колпачками-набалдашниками, отгибаемыми в сторону. С ними скорее можно отнести в категорию крупных.
Сечение основной части корпуса 8*19мм, колпачков 10*21мм, полная длинна 80мм, с отогнутыми колпачками 71мм.
Сравнение с некоторыми другими ssd-образными флешками — Kingston DTMAX на sm2320, и пары раритетов — Sandisk extreme 3.0 (в составе sata контроллера от sandisk и sata-usb моста от fujistu) и SP LM920 на jmf603 (версия jmf601 у которого убрали sata, оставили только встроенный usb2.0).
Колпачки из гибкого пластика, охватывают разьем с трех сторон и отгибаются на слое того же пластика, при этом норовят вернуться в исходное положение и мешаются, упираясь в поверхность с разьемом. Ресурс такого решения тоже под вопросом. Из плюсов разве что пока не отломались — точно не потеряются.
На корпусе есть маркировка с обьемом и отверстие для индикатора активности красного цвета. Колпачки подписаны.
Тестовая система — мать на z690 + i3-12100 + 8GB, W10/22h2.
Usb идентификатор:
USB\VID_13FE&PID_6500&REV_0110
Накопитель определяется как несменный (к слову тоже касается и M80, позиционируемый как «флешка»).
Отформатирован в exfat и содержал программу «Activate Warranty»
Тип файловой системы: exFAT.
Метка тома: SP DS72.
244184064 КБ всего на диске.
262144 байт в каждой единице распределения.
Всего единиц распределения на диске: 953844.
Информация от hdtunepro, из интересного — размер сектора стандартные 512 байт. Информация про sata сугубо виртуальная.
Из-за exFAT трим под w10 ожидаемо не работает
F:\>trimcheck-0.7.exe
TRIM check v0.7 — Written by Vladimir Panteleev
github.com/CyberShadow/trimcheck
Loading continuation data from F:\trimcheck-cont.json…
Drive path: \\.\F:
Offset: 137473556480
Random data: FB 41 B8 E2 09 84 52 94 14 96 F8 CD 5C DA F1 E4…
Reading raw volume data…
Opening \\.\F:…
Seeking to position 137473556480…
Reading 262144 bytes…
First 16 bytes: 14 C0 3C B5 15 09 C1 C3 F5 6A 54 85 7C B8 27 AA…
Data is neither unchanged nor empty.
Possible cause: another program saved data to disk,
overwriting the sector containing our test data.
CONCLUSION: INDETERMINATE.
Re-run this program and wait less before verifying / try to
minimize writes to drive F:.
На NTFS - работает
E:\>trimcheck-0.7.exe
TRIM check v0.7 — Written by Vladimir Panteleev
github.com/CyberShadow/trimcheck
Loading continuation data from E:\trimcheck-cont.json…
Drive path: \\.\E:
Offset: 60936192
Random data: BB 27 51 EA DF ED AD 75 06 60 DF DC 91 67 AD D7…
Reading raw volume data…
Opening \\.\E:…
Seeking to position 60936192…
Reading 16384 bytes…
First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00…
Data is empty (filled with 0x00 bytes).
CONCLUSION: TRIM appears to be WORKING!
К слову txbench, включая 0.98, работать с накопителями такого типа не умеет, ни в разделе data erasing/trim, ни в drive information/ssd optimization. Secure erase — тоже не поддерживается.
Примененный флеш:
v0.2a
Drive: 3(USB)
OS: 6.2 build 9200
Model: SP DS72 PMAPPMAP1234
Size : 238475 MB
Controller : PS5017 (from firmware)
Bank00: 0xad,0x7e,0x28,0x53,0x2,0xb0,0x0,0x0 - Hynix 3dv6-128L TLC 16k 512Gb/CE 512Gb/die
Из других обзоров известны следующие варианты:
MS60/500G fw.UHFM20.2 — bics5/1tb
MS70/500G fw.UHFM00.6 — hy-v6/1tb
MS70/2T fw.UHFM00.6 — ?
DS72/500G fw.UHFM00.6 — ?
DS72/1T fw.UHFM00.6 — hy-v6/1tb/2die/ce
M80/500G fw.UHFM00.6 — hy-v6/1tb/2die/ce
Прошивки с версией вида UHFM2x.x предназначены для bics5/tlc, UHFM0x.x — hynix v6/tlc.
CDI определяет как nvme древней версии, но на самом деле это заглушка, вероятно для реализации доступа к smart'у. более того, этот экземпляр так же изображает sata, и у него можно прочитать smart в sata версии. Цель ровно такая же — совместимость, никаких других команд sata/nvme, кроме считывания идентификации и смарт, прошивка контроллера не поддерживает.
отчет smartctl 7.3 - имитация nvme
smartctl 7.3 2022-02-28 r5338 [i686-w64-mingw32-w10-b19045(64)] (sf-7.3-1)
Copyright © 2002-22, Bruce Allen, Christian Franke,
www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: DS72
Serial Number: P2401244071C464F968A
Firmware Version: UHFM00.6
PCI Vendor/Subsystem ID: 0x0000
IEEE OUI Identifier: 0x000000
Controller ID: 0
NVMe Version: <1.2
Number of Namespaces: 0
Local Time is: Tue Oct 01 16:50:02 2024 RTZ
Firmware Updates (0x00): 0 Slots
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 0.00W — - 0 0 0 0 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 63 Celsius
Available Spare: 100%
Available Spare Threshold: 50%
Percentage Used: 0%
Data Units Read: 135 238 [69,2 GB]
Data Units Written: 136 527 [69,9 GB]
Host Read Commands: 0
Host Write Commands: 0
Controller Busy Time: 0
Power Cycles: 3
Power On Hours: 0
Unsafe Shutdowns: 0
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Read 1 entries from Error Information Log failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=1117
А вот hdtune показывает sata версию smart'а:
И txbench — тоже:
Посмотрим на скорость. Основная часть тестов проводились при обдуве 80мм вентилятором во избежание троттлинга, что происходит без будет показано отдельно. Так же тесты поверх файловой системы выполнялись для раздела отформатированного в NTFS, если не указано иное.
Запись пустого накопителя, 890MB/s в slc-кеш и 360MB/s прямая запись в tlc.
Когда slc-кеш кончается — прямая запись чередуется с провалами до ~10MB/s.
Как это не удивительно, скорость записи после кеша у младшего обьема оказалась выше, чем у известных по обзорам 500/1000GB. Вероятная причина — более емкие собратья успевали перегреться еще до окончания slc-кеша.
Чтение записанного разным блоком, 8M/1M/64k - есть выраженная зависимость, характерная для многих контроллеров от phison, так что под под WinXP будет читаться небыстро
Повторная запись — соответствует участку прямой записи первого прохода, ~360MB/s:
Тоже самое посредством hdtunepro, результаты совпадают:
Потребление — в пределах 1.7Вт на полной скорости, особой разницы между чтением, записью, из кеша или tlc — нет, хотя визуально отличить их на графике можно.
Традиционно для фисона есть оптимизации связанные с записью нулей (и похоже не только нулей).
Потребление — значительно ниже, чем на произвольных данных.
Во многих обзорах наблюдалось многоступенчатое падение скорости в тестах записи полного обьема. Как я и предполагал, причина этого — перегрев и троттлинг, а не какие-то странности slc-кеширования. Судя по невысокой температуре корпуса (максимум порядка 45C) в этот момент тепловой контакт между контроллером и корпусом отсутствует.
Так выглядит запись накопителя без мер по охлаждению. Первый провал — это переход от slc-кеша к прямой записи в tlc, а вот следующие — следствие перегрева
График температуры по смарту от записанного обьема:
И чтение записанного:
Потребление — видно его падение от троттлинга с 1.45Вт до 0.95Вт, потом частичное восстановление до 1.15Вт:
Температура по смарту, дополнительно приведен график с охлаждением (80мм вентилятор сантиметрах в 10):
Троттлинг начинается при достижении 81C по смарту.
А так запись и чтение 64GB посредством hdtunepro. Сначала выполняется запись, и в самом конце виден спад от перегрева. Потом чтение, где скорость сразу понижена, спад продолжается, во второй половине чтения был добавлен обдув и скорость восстановилась.
CDM7/NTFS:
Потребление:
CDM7/exFAT на произвольных данных и нулях
ATTO с разной глубиной очереди
ATTO на разных данных - выделяется только нули, все остальные последовательности в рамках обмена внутри slc-кеша выглядят одинаково
Нули:
Единицы:
Увеличение на 1:
Промзвольные данные:
Отработка trim после удаления файла в 32GB, всплеск потребления длится чуть больше секунды.
Посмотрим на копирование файлов с быстрого источника (netac nv7000 на pcie 4x4) посредством проводника.
Копирование на, 32G файл состоит из единиц (0xFF) — 730/680MB/s, скорость ниже, чем достигнутая в синтетике:
еще 32G — 670MB/s и никакого падения. И тут я вспомнил, что эти файлы состоят из последовательности единиц:
34G уже произвольных данных — в кеш ~700MB/s, кеш закончился и скорость упала до 360MB/s, обьем кеша и скорость после примерно как в синтетике:
еще 34G произвольных данных — кеша нет, 360MB/s несмотря на небольшую паузу
32G файл состояший из последовательности единиц, без паузы, скорость как в кеш и он не кончается.
32G нулей — скорость слегка выше чем в кеш, 740MB/s
Таким образом видно, что скорость записи при копирования ниже, чем в синтетике, кроме того есть «спецобработка» не только последовательности нулей, но и других как минимум 1 и 2 байтных повторяющихся последовательностей, т.е. какие-то зачатки сжатия, что опять же характерно для многих контроллеров от phison.
Копирование обратно идет со скоростью в 800-900MB/s, тут нет ничего интересного.
Про type-C подключение могу сказать что оно есть и работает, максимальная скорость те же самые 10gbps. В том числе с телефонами на примере redmi note9 pro, но покуда там usb2, замерять скорость в них не имеет смысла.
Потребление, как можно было увидеть на графиках выше, умеренное. В простое составляет 0.6Вт и греется по smart'у до 55-60С, переходов в состояние с меньшим потреблением не наблюдалось. При обмене зафиксированный максимум 1.65Вт (прямая запись в tlc). Все это укладывается даже в 0.5А(2.5Вт) для usb2 с запасом.
Подведем итоги. Достаточно быстрая, включая запись больших обьемов, но в тоже время и дорогая, пожалуй все еще флешка (как бы не называл ее производитель). Скорости произвольной записи тоже достаточно высокие, что позволяет использовать и для загрузки полноценной системы без явного дискомфорта. Длительный обмен на полной скорости, как чтения так и записи, приводят к ее перегреву со снижением скоростей даже в минимальном обьеме, у старших обьемов это выражено еще сильнее, как можно убедится в их обзорах.
Последнее поколение UFD контроллеров от phison/smi стирают границы между флешками и внешними ssd, демонстрируя скорости сравнимые с младшими nvme накопителями и обгоняя sata, при это сами контроллеры имеют размеры сравнимые со своими «флешечными» предшественниками, что позволяет упаковывать весь накопитель в типичный флешечный корпус. К сожалению производители не стремятся к этому, продолжая выпускать их в корпусах «внешних ssd», или флешек-переростков, но даже при этом забывая обеспечить нормальное охлаждение.
На мой взгляд SLC кэш для компактных устройств это зло. Когда он заканчивается, контроллер вынужден проводить кучу дополнительных энергоемких операций, таких как чтение из SLC с последующей записью в TLC. И это приводит к перегреву и как минимум в два раза снижает жизненный цикл ячеек памяти. Лучше бы сразу прошивали контроллер для прямой записи в TLC.
самое энергоемкое, как можно видеть — это запись в tlc, хотя разница там и копеечная. когда она чем-то разбавлена, потребление будет ниже. повышенное потребление от фоновых операций может быть разве что при подключении по usb2, когда внешний обмен будет совсем медленный, и в сравнении с ним внутренний может вызывать большее потребление. но в целом пиковые 1.7Вт — это мелочи которые нет смысл обсуждать. хотя в старших обьемах потребление должно быть выше.
у smi поровнее, но один фиг в разы медленее прямой записи. благо наконец стали распространятся прошивки где прямая запись есть.
однако на треть обьема тут теплоемкости таки хватило, это гиг 80. из которых в кеш чуть больше 20.
хранить на флешках инфу — можно только по незнанию или если она совсем уже не нужна.
во1ых копий надо бы больше одной. во2ых не уверен что стоит на это дело пускать именно винт после длительной эксплуатации. хотя 20к часов это, конечно, немного.
необходимость периодической проверки на любых носителях тоже никто не отменял.
В самом начале флешки считались самыми надёжными и долговечными накопителями ввиду одной только «твердотельности», но практика вскоре показала обратное. Сейчас же надёжность на уровне дискет :)
и в документации тогда не стеснялись прямо писать про 10 лет хранения, а не стыдливую отсылку к jesd47.
вообще же тогда многого не замечали. например меряли доступ по чтению и нахваливали. что там на записи творится стало доходить немало лет спустя.
лучше когда карта исправно работает, а не сваливается в r/o. причем последнее не гарантирует целостность информации ни на момент перехода, ни тем более — долговременно.
Пользую два диска по 512Gb пару лет. На боксах с RTL9210.
Оба как мультизагрузочные.
Лезут в любой USB разьем и не мешают. Да малость больше.
Мое ИМХО.
За обзор спасибо.
хотя вот по слухам в ms60/500g нынче попадается этот же самый хиникс, а не терабитный bics5 — изменения бывают в обе стороны. и это наверняка не последний вариант.
а внутри — достаточно быстрые контроллеры, кои еще недавно имели интерфейсы sata/nvme, или на худой конец ufs. но не прямой usb.
Принципиальная разница между usb-флешкой и usb-hdd — магнитная запись против полупроводникового епром(nor, nand и т.д.).
На таком примере вроде бы понятно что принципиально разный способ записи.
А вот «быстрые контроллеры» против «не быстрые контроллеры» — тут как бы не очень понятно в чём ПРИНЦИПиальная разница.
Шифруете архив и закидываете туда параллельно.
хотя последнее время есть тенденция к небольшому с прямой записью после.
Надо прикупить такую флешку.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.