Алюминиевый бокс USB3 с амортизаторами.


Товар куплен с очень значительной скидкой ради обзора. Решил посмотреть на эту железку и сравнить 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 Правил сайта.
Планирую купить +7 Добавить в избранное +8 +12
+
avatar
  • Kraus
  • 01 ноября 2016, 12:55
+3
у меня в глазах двоится от букв Л....?
+
avatar
  • Deorian
  • 01 ноября 2016, 12:57
0
Это секретный сплав такой=) ничего-то ты не понимаешь=)
+
avatar
  • Stress
  • 01 ноября 2016, 12:59
0
да поправьте, «алюминий» пишется с одной «Л»
+
avatar
  • Kraus
  • 01 ноября 2016, 13:01
0
это походу не опечатка, тк автор упорно пишет так и в тексте описания...))
+
avatar
  • tester
  • 01 ноября 2016, 13:03
+1
Аж два раза, да. Вы правы. Исправил, спасибо.
+
avatar
  • Kraus
  • 01 ноября 2016, 13:05
0
всегда пжлст...))
+
avatar
  • neskey
  • 01 ноября 2016, 13:05
+2
Я так над коллегой прикололся. Добавил в словарь word'a, слова с орфографическими ошибками.
+
avatar
  • tester
  • 01 ноября 2016, 13:13
0
Нет мне оправдания :)
«Красные выделения» тоже нужно проверять.
+
avatar
  • lotik
  • 01 ноября 2016, 13:14
+1
QICENT — суббренд ORICO
+
avatar
  • tester
  • 01 ноября 2016, 13:17
+1
Во блин. То есть я, возможно, сравнивал две практически одинаковые, с точки зрения электроники, начинки :(
И поэтому получил практически одинаковые результаты.
Вероятно стоит сравнить «SSD в боксе» с «SSD через SATA».
+
avatar
  • lotik
  • 01 ноября 2016, 22:15
0
Да, так было бы логичнее. Теперь вы, наверное видите в девайсах значительно больше общего.) упаковка, например, практически идентичная.
+
avatar
  • DrHouse
  • 01 ноября 2016, 15:44
0
о них стилистика оформления один в один.
+
avatar
  • lotik
  • 01 ноября 2016, 22:16
0
С языка сняли
+
avatar
  • triante
  • 01 ноября 2016, 13:36
+3
прочитал с ароматизаторами ) какие думаю нафик ароматизаторы? o_O
+
avatar
  • ruditor
  • 01 ноября 2016, 13:40
0
Только хотел написать, а тут вы ))
+
avatar
  • skif31
  • 01 ноября 2016, 13:44
0
наверное, эфирные масла налиты?
+
avatar
  • tester
  • 01 ноября 2016, 14:08
+2
Предложите вариант лучше? :)
У меня есть в запасе «с прокладками», но реклама приучила к иной реакции на этот термин.
+
avatar
+3
Да забейте на эту рекламу и стереотипы… И да, это фиксаторы :-)
+
avatar
  • mooni73
  • 01 ноября 2016, 14:23
0
Ожидал увидеть большой ящик с пружинами внутри.
Ну и вместо каких-то скриптов интереснее выяснить что за сбои у кристалла? Это может быть признаком скрытого дефекта. Пункт 18й подразумевает разборку устройства, фото монтажа и чипа.
+
avatar
  • tester
  • 01 ноября 2016, 14:31
0
Пришлось как-то не особо новый, но дорогущий ноут разбирать. Примерно также была реализована (вибро?)защита — в фиксированный разъём втыкался жесткий диск, а сверху-снизу от «винта» были проложены мягкие силиконовые пластины толщиной 2-3мм.
+
avatar
  • tester
  • 01 ноября 2016, 18:08
+1
Сбои у «КристалМарка» в данном случае не столько сбои, сколько следствие того, что он запущен в эмуляторе-не-эмуляторе (wine = wine is not emulator). То есть обращения к WinAPI транслируются некоей прослойкой к вызовам ядра Linux и системных библиотек.
Соответственно наличие кэширования портит результаты «чтения», задирая их за облака, а наличие той самой прослойки-транслятора портит результаты «записи», опуская их ниже реально существующей скорости.
+
avatar
  • tester
  • 01 ноября 2016, 18:16
0
«Пункт 18й подразумевает разборку устройства, фото монтажа и чипа.»
Покажите мне, пожалуйста, те самые (свежие?) правила, в которых это отмечено. А то при публикации обзора правила немного иные :(
При этом, конечно, не первый раз замечаю «вскрытия» в рамках П18 — что заставляет людей так поступать?
+
avatar
  • lotik
  • 01 ноября 2016, 22:19
0
подразумевает
Выдаёте желаемое за действительное
+
avatar
+1
Несколько циклов измерений показали, что ошибка от измерения к измерению незначительна, то есть вычисленное среднее значение показателей можно считать достаточно точным.
… или что ошибка носит систематический характер)
Средний результат без учёта этого значения также выделен жёлтым.
правильно было бы выделить одинаковым цветом Оба значения, которые игнорим

mooni73
Ну и вместо каких-то скриптов интереснее выяснить что за сбои у кристалла?
настоящий CrystalMark был запущен из-под эмулятора и поэтому, возможно, измерял синтетическое нечто)
скрипты, «которые работают также», можно было бы и выложить, если там есть что-то dirty, а не plane)

mirmirmir
… И да, это фиксаторы :-)
демпферы не всегда безобидны, не-solid state диску они могли бы помешать успеть уйти в защиту при падении
+
avatar
  • tester
  • 01 ноября 2016, 17:09
+1
1. Разброс в измерениях будет всегда, по множеству причин, основная из которых — многозадачность. Тем не менее в любом случае, когда результаты измерений имеют разброс, применяются способы найти что-то близкое к середине. Я применил для расчёта ошибки коэффициент Стьюдента для 32 измерений, из расчёта, что возможно решу сократить количество тестов до 16 (и тогда К Стьюдента будет очень даже кстати).
2. Про цвет. Ну да, он одинаково жёлтый :) Там вообще хватает цветовых проблем, и местами сложностей с пропуском обозначений. Сразу незаметно, а потом начинает глаз мозолить.
3. Скрипты… Там ничего особо сложного. Но, пожалуй, добавлю. Минут через несколько. Добавил, под спойлером перед итогом обзора.
4. О, точно. Демпферы :) То самое слово :)
+
avatar
+2
Плюс за труд и Linux.