Очень высокие задержки при просмотре самбы, как ускорить?

Question

Я получаю доступ к общему ресурсу samba с компьютера с Windows 8.1, и у меня проблема в том, что задержка действительно высока. Открытие файла может занять несколько секунд. Открытие диалоговых окон файлов Windows по сетевому пути или сетевому диску часто приводит к сбою программы. И когда я просматриваю общий ресурс с помощью Проводника и перемещаюсь по файлам с помощью клавиш курсора, он зависает примерно на секунду для каждого файла.

Я уже исключил подключенный сетевой диск из Защитника Windows, что немного ускорило его (казалось, что каждый файл читается для проверки). Однако латентность все еще плохая. Пропускная способность, OTOH, в порядке.

Большинство советов по повышению производительности в Интернете касались увеличения пропускной способности. Я даже не знаю, где начать сокращать задержки. Есть идеи?

Некоторые выдержки из журналов:

При выделении файла в Проводнике:

jason opened file path/to/file.txt read=No write=No (numopen=2)
jason closed file path/to/file.txt (numopen=0) NT_STATUS_OK

При подключении получаю:

setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.

но я не знаю, действительно ли это проблема.

Answer 1

Хорошо, я исправил это, и решение немного странное, поэтому я был бы признателен за пояснения в комментариях :-).

Я скрыл немного информации в этом вопросе, потому что я думал, что это не важно, и не хотел, чтобы люди сосредоточились только на этом. На самом деле я запускаю samba как непривилегированный пользователь на порту 1445. Затем я создал устройство обратной связи в Windows и создал ssh-туннель для привязки моего удаленного порта 1445 (который недоступен за пределами сети компании) к порту обратной петли 445. О, и я делаю это через Wi-Fi :-). Таким образом, существует множество потенциальных узких мест в производительности, но я не хотел, чтобы все указывали, например, на ssh-туннель, в качестве проблемы, так как я знал, что все в порядке (а производительность была в противном случае хорошей).

Оказывается, у петлевого устройства была проблема. Я нашел неясный совет в сети и попробовал, и это сработало. В редакторе реестра я зашел

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID of the loopback device>

Вы можете найти GUID устройства обратной связи, просмотрев все интерфейсы и сравнив значение IPAddress.

Затем я создал два ключа и перезагрузил компьютер:

TcpAckFrequency = 1 (DWORD)
TcpDelAckTicks = 0 (DWORD)

Впоследствии это довольно быстро, и просмотр общих ресурсов выглядит почти как просмотр локального диска. Я должен отметить, что я думаю, что это только удаленно из-за моей неясной установки. На оригинальном сайте, с которого я получил совет (забыл ссылку), предлагалось применить этот метод взлома к реальному сетевому устройству. Поскольку я не уверен, что он на самом деле делает, я бы не рекомендовал делать это, но, поскольку я использую этот сетевой интерфейс только для Samba, он, вероятно, не оказывает негативного влияния на остальную часть системы.