Мобильная версияСтранная обратная пилообразная структура полетных пакетов при передаче TCP [закрыто] ⇐ Linux
-
Anonymous
Странная обратная пилообразная структура полетных пакетов при передаче TCP [закрыто]
Как мы узнали из учебника, мы знакомы с пилообразным паттерном передачи TCP, когда cwnd растет и происходит потеря пакетов (AQM или по другой причине), а затем cwnd падает. После этого cwnd продолжает увеличиваться снова, пока не произойдет еще одна потеря пакета, следовательно, отображается пилообразный шаблон cwnd, независимо от того, используете ли вы кубический или newreno в качестве алгоритма cc.
Я проверяю это с помощью tcp_probe на мобильном телефоне (cubic как cc). в основном включите трассировку ядра Linux для tcp_probe и выполните загрузку iperf3. Но вот что я поймал (https://i.stack.imgur.com/qOuQo.png).
Ось x — время в секундах. Верхняя кривая с точкой оливкового цвета показывает изменение количества пакетов на борту с течением времени. полет кажется явной обратной пилообразной формой, где внезапное увеличение количества впрыскиваемых пакетов затем постепенно снижается из-за получения дальнейших подтверждений. Кроме того, тогда cwnd никогда не меняется и остается на постоянном уровне.
Мой вопрос состоит из трёх частей:
[*]согласно тому, что я узнал о ядре Linux, всякий раз, когда получено подтверждение (что указывает на освобождение окна передачи), оно проверяет, есть ли какой-либо пакет, доступный для отправки (ссылка). почему здесь он не отправляет сразу, а ждет десятки мс, чтобы отправить пакет. и что немаловажно, изменение такого поведения очевидно, поскольку до 61417 секунд он отправлял пакет без каких-либо колебаний. что приводит к этим изменениям. (уровень буфера?) [*]Я заметил эту кривую, когда тестировал как rmnet (сотовая сеть), так и wlan0 (wifi). Я еще не тестировал с eth. эта закономерность относится только к беспроводному трансиверу? или это поведение связано с iperf3? [*]Я провожу небольшое расследование и чувствую, что это связано с «формированием трафика». Но я понятия не имею, чем вызвана эта закономерность.
Как мы узнали из учебника, мы знакомы с пилообразным паттерном передачи TCP, когда cwnd растет и происходит потеря пакетов (AQM или по другой причине), а затем cwnd падает. После этого cwnd продолжает увеличиваться снова, пока не произойдет еще одна потеря пакета, следовательно, отображается пилообразный шаблон cwnd, независимо от того, используете ли вы кубический или newreno в качестве алгоритма cc.
Я проверяю это с помощью tcp_probe на мобильном телефоне (cubic как cc). в основном включите трассировку ядра Linux для tcp_probe и выполните загрузку iperf3. Но вот что я поймал (https://i.stack.imgur.com/qOuQo.png).
Ось x — время в секундах. Верхняя кривая с точкой оливкового цвета показывает изменение количества пакетов на борту с течением времени. полет кажется явной обратной пилообразной формой, где внезапное увеличение количества впрыскиваемых пакетов затем постепенно снижается из-за получения дальнейших подтверждений. Кроме того, тогда cwnd никогда не меняется и остается на постоянном уровне.
Мой вопрос состоит из трёх частей:
[*]согласно тому, что я узнал о ядре Linux, всякий раз, когда получено подтверждение (что указывает на освобождение окна передачи), оно проверяет, есть ли какой-либо пакет, доступный для отправки (ссылка). почему здесь он не отправляет сразу, а ждет десятки мс, чтобы отправить пакет. и что немаловажно, изменение такого поведения очевидно, поскольку до 61417 секунд он отправлял пакет без каких-либо колебаний. что приводит к этим изменениям. (уровень буфера?) [*]Я заметил эту кривую, когда тестировал как rmnet (сотовая сеть), так и wlan0 (wifi). Я еще не тестировал с eth. эта закономерность относится только к беспроводному трансиверу? или это поведение связано с iperf3? [*]Я провожу небольшое расследование и чувствую, что это связано с «формированием трафика». Но я понятия не имею, чем вызвана эта закономерность.
