Пользователи жалуются, что сеанс Webex [4-5 пользователей] в беспроводной сети имеет плохое качество. Как измерить потерю пакетов и задокументировать, что вызывает плохой прием? Спасибо.
решение1
Используйте MTR / WinMTR или эквивалент — он покажет минимальную, максимальную и среднюю задержку, а также потерю пакетов для каждого перехода, включая первый.
Проблема, скорее всего, не связана с Webex (что бы это ни было) — скорее всего, это шум в сети WIFI.
решение2
Отличным инструментом для измерения задержки являетсяТест скорости DSLReports.
Хотя этомогпроблема с Wi-Fi, я думаю, что это гораздо более вероятнобуферраздувание. Раздувание буфера происходит из-за маршрутизаторов, которые ошибочно полагают, что отбрасывать пакеты — это плохо, даже если это означает, что очереди буферов станут огромными, раздутыми и никогда не будут опустошены, тем самым добавляя большую задержку всему, что вы делаете, и блокируя срабатывание алгоритма управления перегрузкой TCP.
Решение заключается в использовании алгоритмов Smart Queuing, таких как fq_codel или PIE, в сочетании с Explicit Congestion Notification (ECN) в блоках, где очереди буфера накапливаются, но никогда не опустошаются. Обычно это блок прямо перед самым медленным соединением, и обычно самым медленным соединением является ваше широкополосное соединение. Так что это обычно касается вашего широкополосного модема или маршрутизатора интернет-шлюза, а также DSLAM или CMTS вашего интернет-провайдера. Smart Queueing достаточно умна, чтобы запускать ECN и, при необходимости, отбрасывать пакеты вместо того, чтобы добавлять слишком много задержек, чтобы контроль перегрузки TCP мог работать.
Если у вас есть буферный раздутый пакет, но вы не можете установить лучшую очередь в тех ящиках, где очереди накапливаются, рассмотрите возможность установки маршрутизатора с хорошей очередью между вашим широкополосным модемом и остальной частью вашей сети, и искусственного ограничения его пропускной способности, чтобы сделать его немного узким местом в обоих направлениях. Это позволяет ему стать местом, где очередибынакопились, но он достаточно умен, чтобы активировать ECN и отбрасывать пакеты, поэтому контроль перегрузки TCP срабатывает до того, как очереди буферов успеют накопиться где-либо в сети.