Скорость потери пакетов с iperf и tcpdump

Я проверил линию на качество связи с iperf. Измеренная скорость (UDP-порт 9005) составила 96 Мбит / с, что вполне нормально, поскольку оба сервера подключены к Интернету со скоростью 100 Мбит / с. С другой стороны, показатель потери дейтаграмм был равен 3,3-3,7%, что я нашел слишком много. Используя протокол высокоскоростной передачи, я записал пакеты с обеих сторон tcpdump. Чем я подсчитал потерю пакетов - в среднем 0,25%. У кого-нибудь есть объяснение, откуда эта большая разница? Какова приемлемая потеря пакетов на ваш взгляд?

Я испытал значительную потерю данных с iPerf в режиме UDP из-за того, что процессор не справлялся. По какой-то причине iPerf с UDP кажется гораздо более загруженным процессором, чем iPerf с TCP. Испытываете ли вы тот же процент потерь, когда устанавливаете iPerf на половину скорости?

Чтобы ответить на ваш второй вопрос о том, насколько приемлема потеря пакетов, это действительно зависит от того, какое приложение вы используете, сколько у вас трафика. Действительно, не должно быть никаких потерь, если вы находитесь ниже предела пропускной способности. В большинстве случаев я бы не стал жаловаться на 0,25%, но это все еще большая потеря, если вы работаете с очень высокими ставками.

[ПРАВКА 1] Некоторые другие мысли, которые у меня были по теме:

1. Попробуйте увеличить ставки iPerf. Если где-то возникает системная проблема, вполне вероятно, что вы будете испытывать одинаковый процент потерь независимо от уровня. Если вы находитесь на пределе своего аппаратного обеспечения, или ваш провайдер делает какое-то КРАСНОЕ , то, скорее всего, не будет потерь до определенного уровня, а затем убыток будет постепенно увеличиваться, чем выше вы идете.
2. Проведите измерение tcpdump сеанса iPerf, просто чтобы убедиться, что ваши тесты точны.
3. Попробуйте iPerf с TCP. Это не будет сообщать о потере, но если вы получаете потерю, то соединение не сможет масштабироваться очень высоко. Поскольку задержка также повлияет на это, не забудьте протестировать конечную точку с минимально возможной задержкой.
4. В зависимости от того, какое устройство находится у вас внутри соединения, убедитесь, что вы находитесь как можно ближе к нему. Например, если у вас есть несколько коммутаторов между вашей тестовой системой и пограничным маршрутизатором, перейдите к напрямую подключенному коммутатору.
5. Если у вас есть управляемый коммутатор, проверьте его статистику, чтобы убедиться, что потери там не происходят. Я столкнулся с некоторыми более дешевыми коммутаторами, которые начинают сбрасываться, когда вы получаете почти 100 Мбит / с трафика UDP на них (в основном это старые и дешевые неуправляемые коммутаторы).
6. Попробуйте одновременно использовать iPerfs с двух разных клиентов на двух разных хостах, чтобы вы могли быть уверены, что ограничение не является результатом использования процессора или дешевой локальной сетевой карты.

Что ж, в TCP есть механизмы для максимального использования одного потока, а в UDP - нет. Таким образом, каждое приложение должно создавать свои собственные механизмы, поэтому, вероятно, каждое приложение использует свой подход для этого. Вероятно, Iperf позволит потерять больше пакетов, потому что пытается достичь максимальной доступной пропускной способности, не заботясь о том, получена информация или нет. Другое приложение, вероятно, попытается не потерять много пакетов и уменьшит скорость передачи пакетов до доступной пропускной способности в соединении.

Использовали ли вы tcpdump для проверки потери пакетов при использовании iPerf, чтобы убедиться, что потеря пакетов, которую вы рассчитываете с помощью tcpdump, соответствует iperf?

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

iperf автоматически отбрасывает пакеты, поступающие не по порядку с UDP? Возможно, вы наблюдаете небольшое дрожание соединения.