[Valeant]

Vtek,
Проблема не в совместимости, так как между самой программой и сетевой картой куча еще есть "примочек". Программе по барабану она вызывает функцию или библиотеку и все. Возможно для данного сервера есть специальные требования, если на XP работало, то можно попытаться из Win7 сделать XP, так как вы не пользуетесь торрентами то можно попытаться вот что выполните команду в cmd.exe

netsh int tcp show global

netsh int tcp set global ? - (подсказка по командам) нас интересует
1.
rss - одно из следующих значений:
disabled: отключение масштабирования на стороне приема.
enabled : включение масштабирования на стороне приема.
default : восстановление заданного по умолчанию состояния масштабирования на стороне приема.

2.
autotuninglevel - одно из следующих значений:
disabled: фиксация значения окна приема по умолчанию.
highlyrestricted: разрешение на увеличение окна приема относительно значения по умолчанию, но очень незначительное.
restricted: разрешение на увеличение окна приема относительно значения по умолчанию, с ограничением увеличения при некоторых сценариях.
normal: разрешение на увеличение окна приема в соответствии с требованиями большинства сценариев.
experimental: разрешение на увеличение окна приема в соответствии с требованиями экстремальных сценариев.

т.е. даем команду
netsh int tcp set global rss=disabled autotuninglevel=disabled

Тем самым вы заставляете ОС принимать данные в буфер только по 64K и не более, после получения данных в буфер, программа их возьмет.

Есть еще два параметра

TcpAckFrequency Идея: Данная настройка задает количество TCP пакетов, которые Windows накапливает (в целях оптимизации) перед отсылкой. Выставление этой настройки в 1 приводит к отсылке нового пакета без накопления нескольких следующих. Реестр - regedit.exe HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\Interfaces\ Дочерними элементами этого ключа будет несколько ключей вида {7DBA6DCA-FFE8-4002-A28F-4D2B57AE8383} Просмотрите их все. Тот, который нам нужен, содержит массу настроек и в качестве одного из значений содержит IP адрес вашего компьютера. Кликните правой кнопкой мыши по свободном пространству в правой части окна. Появиться меню, в котором надо выбрать пункт "Создать/Параметр DWORD" Появится новый параметр, который назовите "TcpAckFrequency". Кликните правой клавишей на созданном параметре и выберите пункт меню "Изменить" В открывшемся окне введите значение 1 TCPNoDelay Идея: Данная настройка снижает Latency за счет отключения одного из внутренних алгоритмов Windows (Nagle algorithm). HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters Найдите параметр (или создайте новый типа DWORD, если не нашли) TCPNoDelay Измените значение найденного параметра на 1 Как это работает? Значение TcpAckFrequency определяет частоту отправки TCP/IP подтверждающего сообщения. Если значение равно 2, TCP/IP будет отправлять подтверждение после 2 принятых сегментов или после принятия 1 сегмента и отсутствия второго сегмента на протяжении 200 миллисекунд. Если значение равно 3, TCP/IP отправляет подтверждение после приема 3 сегментов, или после приема 1 или 2 сегментов и отсутствии последующих сегментов на протяжении 200 миллисекунд. И так далее. Если вам требуется сократить время ответа за счет удаления задержек отправки подтверждений TCP/IP, задайте это значение равным 1. В таком случае TCP/IP будет немедленно отправлять подтверждение для каждого сегмента. Если ваши соединения используются в основном для передачи крупных объемов данных и задержка в 200 миллисекунд несущественна, имеет смысл увеличить это значение для снижения дополнительной нагрузки отправки подтверждений. Ну а если мелкие, такие как наши пакетики ВоВ ) то лучше поставить немедленное. Параметр TCPNoDelay отключает алгоритм Nagl'e. Из алгоритма следует, что в TCP соединении может присутствовать только один исходящий маленький сегмент, который еще не был подтвержден. Следующие маленькие сегменты могут быть посланы только после того, как было получено подтверждение. Вместо того чтобы отправляться последовательно, маленькие порции данных накапливаются и отправляются одним TCP сегментом, когда прибывает подтверждение на первый пакет. Красота этого алгоритма заключается в том, что он сам настраивает временные характеристики: чем быстрее придет подтверждение, тем быстрее будут отправлены данные. В медленных глобальных сетях, где необходимо уменьшить количество маленьких пакетов, отправляется меньше сегментов. Собственно отрубая данный алгоритм мы выигрываем в том что не тратим лишнее время на подтверждение целостности данных... но и целостность наших данных, степень ошибок сразу встает вопросом.... глюки могут случаться чаще... Так что используя данные настройки, мы уменьшаем реально нагрузку... увеличивая проходимость канала и следовательно "уменьшаем" задержку.... Однако при этом страдают такие вещи как скачивание фаилов, службы торрента, ДовнЛоадер вова тоже будет дольше качать патчи.... Потом мы можем терять данные (протокло TCP теряет свое основное преимущество над UDP)

[Vtek]

Valeant,
Спасибо за ответ.
Первую часть сообщения понял, завтра попробую. Если не получится, то в принципе я понял, как вернуть все обратно.
Вторая часть взорвала мой мозг

PS вы начали с "так как вы не пользуетесь торрентами"... А что если я пользуюсь? Торрентс.ру, без него тяжело будет )))

[Vtek]

Valeant,
Заработало! Задержка упала до 30 мс, чего и требовалось!
Однако, на что эта настройка может повлиять еще (торренты, еще что-то)?
Спасибо!

[Valeant]

Весь смысл работы сети - передать пакет и получить ответ как можно за более короткое время, среда передачи и время формирование пакетов одно и то же в Ethernet если рассматривать например такой вариант: какая сеть будет работать быстрее т.е. байт/сек

1. 100 пакетов по 1400байт (в среднем) и подтверждение о приеме каждого переданного задержка из пункта А в Б примерно 250ms, при сбойном повторяем передачу этого сбойного, тем самым уменьшаем пропускную способность сети

2. 100 пакетов по 1400байт (в среднем) но выталкиваем их все сразу, т.е. пока первый идет до адресата мы уже выталкиваем второй, далее третий .... далее 10, т.е. можем не ждать пока первый дойдет до адресата (т.е. за этот интервал в 250ms сколько сможем столько и вытолкнем), подтверждение приходит на n-пакетов сразу, задержка из пункта А в Б примерно 250ms, при сбойном повторяем именно тот пакет который плохой, т.е. если в ста вагонах 26 плохой то повторим только 26.

Одна проблема при втором варианте - при получение данных устанавливается окно приема в Win7 оно теперь не ограниченно, в XP 64К. Представьте себе вы передаете данные в вашей программе, т.е. блок данных не будет обслужен пока не получит подтверждение, ваша программа оперирует очень маленькими объемами данных но в реальном времени и их не надо накапливать для одной большой передачи их нужно сразу отослать, но при перекачке файлов лучше использовать большие блоки для передачи, потому что результат нужен только в самом конце передачи когда на сервере или у клиента произойдет его сборка файла и он клиент сможет запустить полученный файл.

В основном такое еще нужно только в играх, так как информация в сетевой игре о партнерах должна быть оперативной.

Только все нужно рассматривать в комплексе т.к. еще например сетевые платы которые не имеют возможности сами на аппаратном уровне не отвлекая процессор обрабатывать передачу/прием пакетов не могут и будут очень часто отвлекать процессор на обработку этих данных чем чаще тем хуже, по тому что запросы на обработку имеют приоритеты, и если приоритет который требует обработки сетевого пакета, который находится в буфере сетевой карты ниже например обработки запроса от видео карты, то данные в буфере сетевой карты могут быть затерты полученными следующими, т.е следующий приходящий затрет уже имеющиеся данные, тогда нужно будет его повторить.

Так что нюансов много. Это все на пальцах, на деле сложнее.

[Vtek]

Я примерно понял. Думаю стоит попробовать запустить торрент и понять, как повлияет.
Спасибо за помощь.