Свежие комментарии

Не-не, MPEG и прочие подобные - они аппаратно поддержаны. И там API: туда нежатые байты, обратно - жатые. Программно на камерах, понятно, ничего не жмут, процессор слаб.

А когда что-то там конструируют (нашли на свалке сенсор и давай...) или хакают фирмварь готовой камеры, чтобы использовать сенсор неподобающим путем (CHDK, DiagRAW, всякие записи DNG из айфонов), то
- особого места чтобы разгуляться - нету.
- эффективность "на маленьких кусочках" - важна (откуда и появилась, похоже, запись "6 10-битных пикселов в 8 байтах" - эффективно ложится на 64-битную архитектуру, а 1/16 оверхеда - ну насрать)

И "14 бит плотных" (это сколько ж, 4 пиксела в 7 байт, верно?) - ну херовый очень кодек для современных 64-(и тем более 128-256-битных SIMD).
Какой нужно взять блок, чтобы оно эффективно на AVX2 ложилось (256 бит)? Я меньшего куска, чем 224 байта (это 128 пикселов зараз) не придумал, а столько регистров нету.

А не бывает 14-bit uncompressed.
То есть оно "бывает" (та же Sony), но пишут в 16-битном формате тогда, верхние два бита - нули.

Потому что экономия от упаковки копеечная, а геморой на распаковке - просто ой.

Такая экзотическая хрень нужна разработчикам камер и прошивок для них (включая всякие хаки, вроде DiagRAW)

Ну и пользователям подобных хак-прошивок.

Выражаю особую благодорность за создание данной возможности.

Загрузиться с LiveUSB у меня так и не вышло - ни один из современных дистрибутивов почему-то не взлетел в графическом режиме, а в текстовом я свежих не нашёл. Чертовщина какая-то... Искать дальше уже не стал, отложу на потом, когда фаза Луны сменится :)

Вот как-то так получилось с винды на VM линукс.

Т.е. честных 10G там есть, надо только нагружать правильно.

Но про FreeBSD 11 я наврал. Там -CURRENT:

root@iscsi:/home/lexa # uname -a
FreeBSD iscsi.lexa.ru 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r302772M: Wed Jul 13 21:38:55 MSK 2016     root@iscsi.lexa.ru:/usr/obj/usr/src/sys/GENERIC  amd64
 

А на другой стороне так:

lexa@home-gw:~# uname -a
FreeBSD home-gw.lexa.ru 10.3-STABLE FreeBSD 10.3-STABLE #11 r300047M: Tue May 17 16:19:12 MSK 2016     lexa@home-gw.lexa.ru:/usr/obj/usr/src/sys/GENERIC  amd64
 

Дата сборки ядра примерно равна дате svn up

Да тоже нормально

root@iscsi:/home/lexa # iperf -c 10.5.0.1 -t 60
------------------------------------------------------------
Client connecting to 10.5.0.1, TCP port 5001
TCP window size: 35.0 KByte (default)
------------------------------------------------------------
[  3] local 10.5.0.2 port 53177 connected with 10.5.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  69.1 GBytes  9.89 Gbits/sec
 

При этом у меня, конечно так:

ifconfig ix1 10.5.0.2/24 mtu 9000 lro
 

[lexa@iscsi ~]$ pkg info | grep iperf
iperf-2.0.5 Tool to measure maximum TCP and UDP bandwidth

В history нашлись такие ключи:
iperf -w 1024k -l 1M -f m -c 10.6.0.1 -i 900 -t 28800

>> Пытаюсь понять, кто виноват - винда, линукс, гипервизор, или так и должно быть

Ну я надеюсь - постепенной отменой всего вышеперечисленного?

У меня 9.9 в одну сторону и ~15 в сумме было на FreeBSD/FreeBSD (10-я и 11-я версии)

У меня 10G и сеть - быстрее дисков.

Ага, 12-го немцы отправили, 13-го оно выехало из Германии, 16-го утром (сегодня) въехало и сразу прошло таможню.
Так ко вторнику и до Питера доберётся.

Дошли руки. Создал папку с 11111 реальными файлами. samba по гигабитному линку. Открываю папку на windows 7 стандартным Explorer вид отображения таблица (показывает имя, дату изменения, тип, размер). Первое открытие наверно до секунды (с zpool прочиталось около 2MB, по сети передалось до 1,5MB). Повторное открытие папки - доли секунды (с zpool прочиталось 4kB, по сети передалось до 1,5MB). Практически мгновенно появляется список файлов и затем происходит сортировка по имени (или как задано). Я бы не сказал, что это долго :-). Раньше вообще не обращал на это внимание и не возникало никакого дискомфорта.

Скопировал папку на локальный диск windows и стал переключаться между папками. Чуть медленнее. Разница максимум десятые доли секунды.

А кто говорил, что трафика не должно быть? По моему в предыдущий раз я как раз настаивал, что он (оверхед) должен быть :-). Нужно разбираться в конкретном случае. Какие настройки recordsize, logbias, sync, redundant_metadata? По памяти не помню, но проверить что у нас там есть по sysctl на эту тему. Желательно знать какой размер блока у ntfs на данном томе?

Немного непонятно, что вкладывается в понятие "- метадату надо (констистентно) писать с sync
- а данные - как приложение велело".
Условно по iscsi на zvol или любое другое блочное устройство на исполнение передаются четыре команды (в терминологии FreeBSD) READ, WRITE, FLUSH, DELETE. Если посмотреть на статистику, то ntfs не злоупотребляет командой FLUSH :-). Проблема в zvol и его настройке. Если с помощью geom-ов на тех же дисках организовать блочное устройство и отдать его по iscsi, то с производительностью резко повеселеет :-).