AlexKBгде-то на уровне провайдеров, сетевого канального оборудования, всего того, чем я не владею...Наблюдал, как этим занимаются специалисты, и немного занимался этим сам.
Надо искать узкое место - слабое звено. Меня бы встревожил уже ping > 100ms (в нашей системе ping > 50ms недопустим, хорошим значением считается 25ms).
Для моделирования трафика есть специальные утилиты (e.g. iperf), но часто применяют простейшие приёмы:
1)
a. ping -t <тот конец>
b. ping -t <какой-нибудь популярный и-нет ресурс, который должен отвечать быстро>
если большая разница между a и b, <подозрение на провайдера на том конце> либо <на том конце что-то не так настроено>;
если a и b одинаково плохо, <подозрение на провайдера на нашем конце> либо <на нашем конце что-то не так настроено>.

2) Далее можно искать, какое именно звено тормозит, если неясно, в сети какого провайдера проблема. Утилиты: pathping (windows), nmap (linux).

Такая вот муторная работа. Задержки скорее всего на стадии установления соединения: 3 минуты > всех разумных tcp-таймаутов, вы скорее всего делаете повторные попытки установления соединения на прикладном уровне. Установление соединения - вообще самая уязвимая операция, вспомните, как часто при плохом и-нете приходится жать на Ctrl-F5 в браузере. Понимаю, что софт править нелегко, но если перейти на постоянные сеансы, ситуация с задержками может улучшиться.

AlexKB,

извини, ошибся с 3 минутами :)
Тестируя сетку, лучше действовать на уровне утилит ОС.
Даже простенький непрерывный 'ping -t ip-address' позволяет собрать статистику по потерям пакетов и колебаниям времени ответа (в Cache это, конечно, можно заскриптовать, но смысл?)

tracert | pathping | nmap могут помочь найти тормозящую сеть/хост.

servit,

у каждого конечно свой опыт, но:

servitЧто метод CheckAddressExist и делаетОн совсем другое делает: шлёт всего один пакет (-n 1), я же предложил непрерывный ping; добавлю к этому, что на длительное время (на 1 час как минимум).

servitЭто могут быть константы жёстко вшитые в код В код вшито '-w 1000' - этого всего лишь время ожидания ответа (в мс), а не принудительная задержка. Как вы, конечно, знаете, ping работает не по tcp, а по icmp, поэтому время ожидания надо задавать явно.

AlexKB, а вот случайно и про 3 сек нашёл: Microsoft TechNet. Appendix A: TCP/IP Configuration ParametersTcpInitialRTT
Key: Tcpip\Parameters\Interfaces\interfaceGUID
Value Type: REG_DWORD—number
Valid Range: 0–0xFFFF
Default: 3
Description: This parameter controls the initial time-out in seconds used for a TCP connection request and initial data retransmission on a per-interface basis. Use caution when tuning with this parameter because exponential backoff is used. Setting this value to larger than 3 results in much longer time-outs to nonexistent addresses

Возможно, совпадение, но подтверждает начальное предположение, что проблема возникает при установлении соединения.