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

Где что? Не удалось нагрузить 18 ядер? У пользователя, утилитой SonyPixelShift2DNG, но у FRV будут те же проблемы, без модификаций он 18 (36) ядер не выжрет.

Надо сказать, что вот утилизация 18 ядер (36 с HT) оказалась некоей проблемой, которую по переписке не решили.

Дело идет к socket 2066

FastRawViewer про скорость, c JavaScript ему не по пути.
См. например, https://www.reddit.com/r/programming/comments/612v99/vs_code_uses_13_cpu...

флешка тоже не самый частый зверь в эпоху онлайн и сервисов. Так, систему переставить с образа :)

Скорее всего. Печаль.

Ну это пока не захочется странного. К примеру (стреляю наугад) PTP/MTP. Из native-программы можно сходить к native API, вот просто взять и сходить, а из JS - утомишься (ну то есть пойдешь и сделаешь bindings свои, да).

Или вот "media change detection" (или не detection, а просто флешку размонтировать). Какой нахрен электрон?

Для простых задач, которые ничего такого не предполагают - ну да, в известной степени да.

> ежики плачут, колются, используют

Но если OpenGL не нужен, то JS всех пожрал. Веб, или Электрон..

wxWidgets это нездоровая копия парадигм MFC в кроссплатформенном фантике. QT при всех своих недостатках намного лучше особенно если нужна работа под Мак и Windows.

Перечитал на свежую голову. Вчера не заметил, что 16MB окна не оказали решающего влияния. Но раз начали про сетевую задержку лучше лишний раз убедиться, что всё нормально. Я пользуюсь локально fio, но для единичной очереди сойдёт и dd.
dd if=/data/admin/test_64g of=/dev/zero bs=4k
68719476736 bytes transferred in 331.212954 secs (207478228 bytes/sec)
Зная локальную производительность и производительность по сети можем грубо оценить задержку которую вносит сеть при чтении 4к блоков. Мой файл забит нулями с lz4 сжатием и recordsize=128k.
Для контроля - единичная очередь для 128k блоков для моей линейки:
diskspd -W0 -d20 -s -b128k -o1 I:\Test_64g
0 | 16796483584 | 128147 | 800.93 | 6407.41 | I:\Test_64g (64GB)
dd if=/data/admin/test_64g of=/dev/zero bs=128k
68719476736 bytes transferred in 13.461554 secs (5104869350 bytes/sec)

Теперь о пропускной способности. Очередь которую мы задаем в diskspd позволяет разогнать и поддерживать окно передачи по сети для утилизации полосы пропускания. Для моей линейки ещё мало:
diskspd -W0 -d30 -s -b128k -o12 I:\Test_64g
0 | 36426481664 | 277912 | 1157.96 | 9263.71 | I:\Test_64g (64GB)
А вот наступает полная утилизация:
diskspd -W0 -d30 -s -b128k -o13 I:\Test_64g
0 | 36989042688 | 282204 | 1175.84 | 9406.71 | I:\Test_64g (64GB)
Можно грубо оценить достаточный размер окна. Дальнейшее увеличение глубины очереди не добавит производительности и будет упираться в полосу пропускания сети.

Про тюнинг самбы. Помню тоже переносил какие-то конфиги. Когда наступила пора разобраться всё убрал и с помощью testparm -v посмотрел, что там по умолчанию. Оказалось почти полностью совпадало с конфигом. Зачем писать лишнее? socket options точно отличался. Глянул в man smb4.conf, а там предостережение. Решил отдать всё на откуп системе. Как это повлияло на производительность уже не помню, но хуже точно не стало. С тюнингом сети была похожая ситуация. В очередной раз решил не копировать конфиг и по мере возникновения узких мест разбираться. У меня узкие места не возникали :-). Для моей линейки имею по умолчанию:
net.inet.tcp.sendbuf_max: 2097152
net.inet.tcp.sendbuf_inc: 8192
net.inet.tcp.sendbuf_auto: 1
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
net.inet.tcp.recvbuf_max: 2097152
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.recvbuf_auto: 1
Все результаты получены с этими параметрами.

По поводу подозрений на win. Так как изменения произошли после корректировки на FreeBSD и конфиги были идентичны наверно стоит пока немного отложить подозрения на win.

wxWidgets совсем никак супротив QT?

Впрочем, старый ящик то под парами, можно и линейку.
0 | 12934684672 | 3157882 | 616.77 | 157892.62 | file64g.img (64GiB)
Ну и трафик похожий на измерения, 5Gbit/s примерно
Повторяемость разумная:
0 | 13108097024 | 3200219 | 625.04 | 160008.97 | file64g.img (64GiB)

Я имел ввиду весь стек прохождения, читаемого блока. А эксплорер молодец, выжимает всё что может :-). До прерываний я не доходил, пока не было нужды. Расчехлил свою линейку, может поможет найти кто тормозит.
11.1, samba 4.4, MTU 9000 (все сетевые настройки и настройки самбы по дефолту), win 10 (не помню, чтобы что-то тюнил).
diskspd -W0 -d20 -s -b4k -o1 I:\Test_64g
0 | 7923531776 | 1934456 | 377.83 | 96724.31 | I:\Test_64g (64GB)
Почти 97k IOPS. Теперь смотри сколько у тебя.

Латентность может быть не (только) у оборудования, а у всего стека.

Как я тут уже выше написал, мне непонятна история с прерываниями:
ssh - 25k прерываний в секунду, чуть меньше чем "прерывание на пакет"
mbuffer - 80k, аналогичная история.
smbd - меньше трех тысяч. При этом пакетов в одну сторону: 900Mb/9k => 100k пакетов/сек. Т.е. 30 пакетов сворачиваются в одно прерывание? Или кто-то поллит?

При этом mbuffer я сегодня вот не щупал, а ssh/smbd - на одних настройках.

Задирание окон приема/передачи и размера передаваемого блока для увеличения пропускной способности намекает на высокую latency при передаче. Что является причиной пока не ясно, пока подтверждена только пропускная способность оборудования. Я так понимаю explorer показывает меньше?