Итак что надо подправить в реестре виндовс:

1 - TcpAckFrequency

Пуск->выполнить-> пишем regedit -> ищем HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\

Там будет несколько интерфейсов {2D352-42A34-234F23-42223} тут надо найти нужный. Нужен тот где вы найдёте свой IPадрес - это интерфейс для интернета ( Свой ипадрес можно посмотреть тыкнув в мониторчики в трее около часов и выбрав там 'состояние')
После того как нашли свой интернетовский интерфейс добавляем двоичный DWORD параметр(если нету) TcpAckFrequency и в свойстве ставим '1' . (По умолчанию windows ставит '2' )

2 - TCPNoDelay

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters (Если нету такого, то создаём, пишем с учетом регистра - большие буквы большими, маленькие маленькими как тут написано, реестр чувствителен к этому)

В 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 сегментом, когда прибывает подтверждение на первый пакет. Красота этого алгоритма заключается в том, что он сам настраивает временные характеристики: чем быстрее придет подтверждение, тем быстрее будут отправлены данные. В медленных глобальных сетях, где необходимо уменьшить количество маленьких пакетов, отправляется меньше сегментов.

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

Так что используя данные настройки, мы уменьшаем реально нагрузку... увеличивая проходимость канала и следовательно "уменьшаем" задержку....