Товар куплен с очень значительной скидкой ради обзора. Решил посмотреть на эту железку и сравнить QICENT с Orico.
Тесты скорости проведены в Linux, как с реальными задачами (копирование файлов), так и с искусственными тестами типа копирования «из памяти на диск». В качестве начинки бокса для тестов использован SSD Kingston.
П18, Linux, dd, fio и прочие подозрительные вещи — в наличии :)
Для начала внешний вид и ощущения.
Упаковка:
Размеры QICENT, если сравнивать с Orico (сравнивал с этой моделью —
mySKU.me/blog/aliexpress/36281.html) не особо отличаются: толщина практически равна (или, если не считать ножки-пупырышки у орико за толщину, то QICENT на 0.5мм толще), ширина у них равна, длина больше на 6мм у обозреваемого QICENT.
Вес у обозреваемого 87 грамм, против 55 «ориковских» грамм, но это не просто так — две половинки корпуса это алюминий толщиной около 0.9мм (измерить более точно нечем).
Сам бокс упакован в явно не многоразовый тонкий матовый пакет, под ним картонная крышка, скрывающая кабель и амортизаторы.
Вот они, амортизаторы:
Диск в боксе:
USB3:
Защёлка держит крышку очень прочно. Чтобы открыть бокс так, как это задумано, нужно сдвинуть вбок «кнопку», которая на панели с USB разъёмом (на тройной картинке — слева). Сдвигаем кнопку и удерживаем её, и далее сдвигаем крышку по длине — крышка легко снимается. Сама, случайно, не откроется, и чтобы открыть через силу, нужно очень постараться. У меня ушло на насильное открытие около двух минут. Я справился — свернул защёлку (средняя картинка из трёх), вы так не делайте. На трёх картинках, полагаю, понятно что и как работает.
Теперь защёлка держит гораздо хуже :)
Нижнюю крышку, которая скрывает схему, сдвинуть так и не смог, как ни старался. Применял даже резиновые перчатки, чтобы усилить сцепление. Не получилось. Поэтому фото внутренностей не имею.
Решил начать c простых тестов прямой записью на устройство, минуя файловую систему:
Запись на устройство, USB3
dd if=/dev/zero of=/dev/sdd conv=noerror,sync bs=512K count=10000 oflag=direct
скопировано 5242880000 байт (5,2 GB), 24,7455 c, 212 MB/c
dd if=/dev/zero of=/dev/sdc conv=noerror,sync bs=512K count=100000 oflag=direct
скопировано 52428800000 байт (52 GB), 249,398 c, 210 MB/c
Чтение, USB3
dd of=/dev/null if=/dev/sdc conv=noerror,sync bs=512K count=10000 iflag=direct
скопировано 5242880000 байт (5,2 GB), 24,7381 c, 212 MB/c
dd of=/dev/null if=/dev/sdc conv=noerror,sync bs=512K count=10000
скопировано 5242880000 байт (5,2 GB), 26,0036 c, 202 MB/c
И понеслось :)
(Далее все USB2 тесты были выполнены на боксе, подключенном обычным микро-usb кабелем, которым я заряжаю телефон. Подключение USB3 было через комплектный кабель от QICENT)
Захотелось CrystalMark, но он, будучи запущен под wine, показал, как мне кажется, совсем уж неадекватные результаты, судите сами:
Дабавлю из комментариев. Сбои у «КристалМарка» в данном случае не столько сбои, сколько следствие того, что он запущен в эмуляторе-не-эмуляторе (wine = wine is not emulator). То есть обращения к ядру (и системным библиотекам Windows) от windows-программы транслируются некоей прослойкой к вызовам ядра Linux и соответствующих системных библиотек.
Соответственно наличие кэширования портит результаты «чтения», задирая их за облака, а наличие той самой прослойки-транслятора портит результаты «записи», опуская их ниже реально существующей скорости, поскольку цепь от обращения до исполнения удлиняется.
Вместо этого запилил свой собственный тест с источником SSD, для начала копируя большой файл, примерно так
dd if=/mnt/2/filesrc of=/mnt/1/filedst bs=512K oflag=direct
А затем — примерно 32 гига разного барахла с каталога /home (в винде это c:\users, видимо). А там куча мелких файлов — примерно 60 тысяч файлов одной только «мелочи» типа кэша браузеров, миниатюр картинок и прочей «полезной» разности.
time cp -R -t /mnt/1 /home/*
Вот результаты:
Жёлтым в серии измерений выделил неожиданно выбивающееся из серии значение. Примерно на то время должен был попасть запуск скрипта создания страховой копии, так что считаю это нормальным. Средний результат без учёта этого значения также выделен жёлтым.
Итого 200 МБ/сек запись одного файла, и 68 МБ/сек запись кучи разношерстного барахла. (одинаковый результат меня тоже смутил, и это не опечатка).
Но и этого показалось мало :) Я захотел КристалМарк :) Поэтому был создан не особо хитрый, но довольно грязный скрипт, позволяющий провести серию измерений скорости записи и чтения при помощи dd и fio, и получить среднее значение. Тесты как в КристалМарке — последовательная запись и последовательное чтение, а также запись и чтение случайно расположенными блоками по 4К.
Несколько циклов измерений показали, что ошибка от измерения к измерению незначительна, то есть вычисленное среднее значение показателей можно считать достаточно точным.
Погрешности в итоговом виде скрипта считаны по формулам отсюда (ссылка на методику обработки результатов измерений) —
teachmen.ru/methods/phys_prac6.php и отображены в таблице USB3 в виде (+-хххх)
Скрипт
Тот, что "заменитель КристалМарка". Файловая система тестового носителя должна быть примонтирована в /mnt/1 - именно поэтому в скрипте грязно :)
#!/bin/bash
# размер блока для операций последовательного чтения и записи
sizeM=512
# размер блока для операций 4К-случайного чтения и записи
sizeMr=256
# iodepth для fio, (вроде как количество потоков, каждый из которых читает или пишет свои собственные блоки размера 4К)
iodepth=32
# количество тестов, из которых расчитывается среднее значение
maxpass=32
wss=0
rss=0
wrs=0
rrs=0
iws=0
irs=0
for i in `seq 1 ${maxpass}`; do
LANG=C dd if=/dev/zero of=/mnt/1/1234${i} conv=noerror,sync bs=1M count=$sizeM oflag=direct 2> /tmp/1.tmp
seqwritet=`tail -n 1 /tmp/1.tmp | sed -n -r -e 's/^.*, ([^,]{1,}) MB\/s$/\1/p'`
seqwrite[$i]=`echo "scale=0; $seqwritet*1024" | bc | awk -F '.' '{print $1}'`
rm -f /tmp/1.tmp
wss=`echo "${wss}+${seqwrite[$i]}" | bc`
wsm=`echo "${wss}/${i}" | bc`
LANG=C dd of=/dev/null if=/mnt/1/1234${i} conv=noerror,sync bs=1M count=$sizeM iflag=direct 2> /tmp/1.tmp
seqreadt=`tail -n 1 /tmp/1.tmp | sed -n -r -e 's/^.*, ([^,]{1,}) MB\/s$/\1/p'`
seqread[$i]=`echo "scale=0; $seqreadt*1024" | bc | awk -F '.' '{print $1}'`
rm -f /tmp/1.tmp
rss=`echo "${rss}+${seqread[$i]}" | bc`
rsm=`echo "${rss}/${i}" | bc`
fio --name=test --blocksize=4k --rw=randwrite --direct=1 --buffered=0 --ioengine=libaio --iodepth=${iodepth} --filename=/mnt/1/1234${i} --size=${sizeMr}M > /tmp/1.tmp
iopsw[$i]=`cat /tmp/1.tmp | grep -G 'write.*iops' | sed -n -r -e 's/.*iops=([0-9]{1,}),.*/\1/p'`
spdtext=`cat /tmp/1.tmp | grep -G '^Run status' -A 1 | tail -n 1`
resspdw[$i]=`echo "$spdtext" | sed -n -r -e 's/.*aggrb=([^,]{1,})(KB\/s),.*/\1/p'`
wrs=`echo "${wrs}+${resspdw[$i]}" | bc`
iws=`echo "${iws}+${iopsw[$i]}" | bc`
wrm=`echo "${wrs}/${i}" | bc`
iwm=`echo "${iws}/${i}" | bc`
fio --name=test --blocksize=4k --rw=randread --direct=1 --buffered=0 --ioengine=libaio --iodepth=${iodepth} --filename=/mnt/1/1234${i} --size=${sizeMr}M > /tmp/1.tmp
iopsr[$i]=`cat /tmp/1.tmp | grep -G 'read.*iops' | sed -n -r -e 's/.*iops=([0-9]{1,}),.*/\1/p'`
spdtext=`cat /tmp/1.tmp | grep -G '^Run status' -A 1 | tail -n 1`
resspdr[$i]=`echo "$spdtext" | sed -n -r -e 's/.*aggrb=([^,]{1,})(KB\/s),.*/\1/p'`
rrs=`echo "${rrs}+${resspdr[$i]}" | bc`
irs=`echo "${irs}+${iopsr[$i]}" | bc`
rrm=`echo "${rrs}/${i}" | bc`
irm=`echo "${irs}/${i}" | bc`
printf "P: %03d\tWs: %d\tRs: %d\tWr: %d (%d)\tRr: %d (%d)\n" $i $wsm $rsm $wrm $iwm $rrm $irm
done
ws_ds='0'
rs_ds='0'
wi_ds='0'
ri_ds='0'
for i in `seq 1 ${maxpass}`; do
ws_d2[$i]=`echo "scale=4; (${wsm}-${seqwrite[$i]})^2" | bc`
ws_ds=`echo "scale=4; ${ws_ds}+${ws_d2[$i]}" | bc`
rs_d2[$i]=`echo "scale=4; (${rsm}-${seqread[$i]})^2" | bc`
rs_ds=`echo "scale=4; ${rs_ds}+${rs_d2[$i]}" | bc`
wi_d2[$i]=`echo "scale=4; (${wrm}-${resspdw[$i]})^2" | bc`
wi_ds=`echo "scale=4; ${wi_ds}+${wi_d2[$i]}" | bc`
ri_d2[$i]=`echo "scale=4; (${rrm}-${resspdr[$i]})^2" | bc`
ri_ds=`echo "scale=4; ${ri_ds}+${ri_d2[$i]}" | bc`
done
ws_dt=`echo "scale=0; sqrt(${ws_ds}/(${maxpass}*(${maxpass}-1)))*2.042" | LANG='C' bc | awk -F '.' '{print $1}'`
rs_dt=`echo "scale=0; sqrt(${rs_ds}/(${maxpass}*(${maxpass}-1)))*2.042" | LANG='C' bc | awk -F '.' '{print $1}'`
wi_dt=`echo "scale=0; sqrt(${wi_ds}/(${maxpass}*(${maxpass}-1)))*2.042" | LANG='C' bc | awk -F '.' '{print $1}'`
ri_dt=`echo "scale=0; sqrt(${ri_ds}/(${maxpass}*(${maxpass}-1)))*2.042" | LANG='C' bc | awk -F '.' '{print $1}'`
printf "\nWrite: %d[%s]\nRead: %d[%s]\nWrite 4K: %d[%s] (%d iops)\nRead 4K: %d[%s] (%d iops)\n" $wsm "${ws_dt}" $rsm "${rs_dt}" $wrm "$wi_dt" $iwm $rrm "$ri_dt" $irm
exit 0
Итоги.
Существенных различий в скорости чтения/записи с другим популярным контейнером не наблюдается, разве что в тестах 4К-блоками QICENT совсем немного, но стабильно быстрее. Стабильность работы никаких нареканий не вызвала.
Амортизация жесткого диска силиконовыми (или из мягкой резины?) вкладышами кажется мне очень полезной, и я даже готов на то небольшое увеличение размеров корпуса, которое вызывается таким техническим решением. Понятно, что при падении сработает такая амортизация далеко не всегда, а «смотря как упадёт». Однако данная конструкция уж точно более безопасна при нажатии на контейнер, чем прочие решения, виденные мной. А давление именно на крышку жесткого диска — одна из частых причин выхода из строя механических ноутбучных HDD. Образец, который я использовал для сравнения (пластиковый орико), не вызывает у меня ощущения, что обычному, механическому жесткому диску, будет безопасно жить в такой тесноте и в достаточно гибком пластике.
Поэтому на подарок родственникам однозначно отдам именно QICENT — и подарить не стыдно, и не страшно за HDD, который будет жить в этом корпусе, то есть меньше опасений за сохранность данных.
Товар предоставлен для написания обзора магазином. Обзор опубликован в соответствии с п.18 Правил сайта.
«Красные выделения» тоже нужно проверять.
И поэтому получил практически одинаковые результаты.
Вероятно стоит сравнить «SSD в боксе» с «SSD через SATA».
У меня есть в запасе «с прокладками», но реклама приучила к иной реакции на этот термин.
Ну и вместо каких-то скриптов интереснее выяснить что за сбои у кристалла? Это может быть признаком скрытого дефекта. Пункт 18й подразумевает разборку устройства, фото монтажа и чипа.
Соответственно наличие кэширования портит результаты «чтения», задирая их за облака, а наличие той самой прослойки-транслятора портит результаты «записи», опуская их ниже реально существующей скорости.
Покажите мне, пожалуйста, те самые (свежие?) правила, в которых это отмечено. А то при публикации обзора правила немного иные :(
При этом, конечно, не первый раз замечаю «вскрытия» в рамках П18 — что заставляет людей так поступать?
правильно было бы выделить одинаковым цветом Оба значения, которые игнорим
настоящий CrystalMark был запущен из-под эмулятора и поэтому,
возможно, измерял синтетическое нечто)скрипты, «которые работают также», можно было бы и выложить, если там есть что-то dirty, а не plane)
демпферы не всегда безобидны, не-solid state диску они могли бы помешать успеть уйти в защиту при падении
2. Про цвет. Ну да, он одинаково жёлтый :) Там вообще хватает цветовых проблем, и местами сложностей с пропуском обозначений. Сразу незаметно, а потом начинает глаз мозолить.
3. Скрипты… Там ничего особо сложного.
Но, пожалуй, добавлю. Минут через несколько.Добавил, под спойлером перед итогом обзора.4. О, точно. Демпферы :) То самое слово :)