Iperf: На выходе JSON отсутствует пропускная способность приемника для UDP

Верно. Это очень старая ошибка, которая могла присутствовать в iperf3 с самого начала. Я как бы понял это (почему я не написал по этому поводу?), Когда работал над № 562. Как вы правильно заметили, тесты UDP не разбивают статистику на стороне клиента и на стороне получателя отдельно. Я не уверен, является ли то, что сообщается, клиентом, отправителем или их смесью. Мне тоже непонятно, чем отличается TCP.

Было бы хорошо, если бы тесты UDP могли выдавать статистические данные, которые больше похожи на TCP в этом отношении (как на стороне отправителя, так и на стороне получателя отдельно), хотя я не уверен, как поддерживать какую-то совместимость с программами, которые используют существующий JSON. выход. (В # 562 я исправил удобочитаемый вывод для UDP, который вы представили в своем первом фрагменте вывода ... В этом случае меня меньше беспокоила обратная совместимость, потому что программы все равно не должны пытаться прочитать этот вывод.)

Есть ли какое-либо решение этой проблемы для вывода UDP JSON? Мы пытаемся разобрать вывод JSON, но не знаем, что к чему. Пример вывода JSON: -

    }],
            "sum":  {
                    "start":        0,
                    "end":  10.004644870758057,
                    "seconds":      10.004644870758057,
                    **"bytes":        4364528380,**
                    "bits_per_second":      3484585580.8672519,
                    "jitter_ms":    2.3222640079292773,
                    "lost_packets": 2102766,
                    "packets":      2989403,
                    "lost_percent": 70.34066668160834
            },

но мы не уверены, что это за байты, отправленные байты или полученные байты?

Когда это будет исправлено? Мне нужно получить бит / с приемника из вывода JSON.

Может есть какое-то обходное решение?

Сейчас этого нет в дорожной карте. Чтобы исправить это, на самом деле требуется изменить конечный автомат и протокол между клиентом и сервером.

Могу я спросить ... Если тестирую с UDP, я разбираю json со стороны клиента и получаю

end.sum.bits_per_second     AND 
end.sum.lost_packets

Смогу ли я получить достоверное представление о том, отправляет ли передача и принимает данные со стороны сервера? Что мне нужно сделать, чтобы убедиться, что отправка / получение в обоих направлениях прошла успешно? Разберите текст, выводимый из:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.000 ms  0/81 (0%)  sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.052 ms  0/81 (0%)  receiver

@awardblvr : Я думаю, это зависит от того, как вы определяете «успешный». Я полагаю, что одной мерой может быть то, что если end.sum.lost_packets равно нулю, то получатель не обнаружил потерянных пакетов. Однако есть некоторые крайние случаи, связанные с этим, в основном связанные с тем, что происходит с пакетами, которые все еще находятся в пути, когда клиент объявляет тест завершенным.

Спасибо ..., я только хочу знать, что могу прочитать этот ОДИН вывод json и увидеть
ОСНОВНО, что пакеты, переданные с сервера -> клиент, и пакеты
передано от клиента -> сервер прибыл и что не было потеряно
пакеты в пакетах, полученных клиентом:

Я считаю, что это:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- НОВИНКА с ПАТЧОМ
end.sum_receiver.lost_packets <--- НОВОЕ с ПАТЧОМ

Пожалуйста, поправьте меня, если я ошибаюсь!

"конец": {
"сумма": {
«конец»: 10.00,
«секунды»: 10.00,
"bits_per_second": 1058280.26,
«байты»: 1322892,
«пакетов»: 81,
"начало": 0,
«jitter_ms»: 0,056,
"lost_packets": 0,
"lost_percent": 0
},
"потоки": [
{
"udp": {
«конец»: 10.00,
«розетка»: 5,
«секунды»: 10.00,
"bits_per_second": 1058280.26,
«байты»: 1322892,
«пакетов»: 81,
"out_of_order": 0,
"начало": 0,
«jitter_ms»: 0,056,
"lost_packets": 0,
"lost_percent": 0
}
}
],
"sum_sender": {<--- НОВИНКА с ПАТЧОМ
«конец»: 10.00,
«секунды»: 10.00,
"bits_per_second": 1058280.26,
«байты»: 1322892,
«пакетов»: 81,
"начало": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": {<--- НОВОЕ с ПАТЧОМ
«конец»: 10.00,
«секунды»: 10.00,
"bits_per_second": 1058271.16,
«байты»: 1322892,
«пакетов»: 81,
"начало": 0,
«jitter_ms»: 0,0568,
"lost_packets": 0,
"lost_percent": 0
}

Спасибо

-А

13 сентября 2018 г., 10:04, Брюс А. Ма [email protected]
написал:

@awardblvr https://github.com/awardblvr : Я думаю, это зависит от того, как вы
определить «успешный». Я полагаю, что одной мерой может быть то, что если
end.sum.lost_packets равен нулю, значит, получатель не обнаружил потерянных
пакеты. Однако есть некоторые крайние случаи, в основном связанные с
что происходит с пакетами, которые все еще находятся в полете, когда клиент
объявляет тест завершенным.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Возникла аналогичная проблема с отсутствием независимых Ч / Б Tx / Rx для UDP.
Использовал другой подход.

Я рассчитал RxMbps, используя TxRate и Drop%.

TxMbps = result.Mbps
RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))

Сервер --- 10 Мбит / с --- SRX (Маршрутизатор) --- 5 Мбит / с ----- Клиент
(Формирователи трафика, примененные к интерфейсам SRX)

Тестирую оба направления при 20 Мбит / с.

Загрузка iPerf3 UDP:

Пульт: 10.8.8.100
Местный: 10.9.9.222
Протокол / порт: UDP / 33333
Время начала: вс, 10 января 2021 г., 03:51:23 GMT
Продолжительность (сек): 10
Скорость передачи: 20,0 Мбит / с
Скорость приема: 9,58 Мбит / с
Джиттер: 0,7 мс
Потерянные пакеты: 8990
Процент проигрышей: 52,07%
Локальный ЦП: 9,03%
Удаленный ЦП: 0,76%

iPerf3 UDP Скачать:

Пульт: 10.8.8.100
Местный: 10.9.9.222
Протокол / порт: UDP / 33333
Время начала: вс, 10 января 2021 г., 03:51:38 GMT
Продолжительность (сек): 10
Скорость передачи: 20,0 Мбит / с
Скорость приема: 4,82 Мбит / с
Джиттер: 0,49 мс
Потерянных пакетов: 13172
Процент проигрышей: 75,9%
Локальный ЦП: 2,5%
Удаленный ЦП: 8,26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _", вероятно, вообще не будет работать. Это связано с тем, что данные собираются только локально, а не с удаленного конца. Например, в отправленных вами данных пропускная способность канала от сервера к клиенту составляет 5 Мбит / с. Однако, предполагая, что загрузка выполняется с сервера на клиент, у вас будет скорость 10 Мбит / с на сервере. Это связано с тем, что это показатель пропускной способности сервера SRX, а не сквозной.

@ bmah888 , поскольку данные сервера могут быть получены с использованием --server-output , следующий подход может быть использован в качестве решения / обходного пути для проблемы сводной статистики UDP JSON:

1. Разделы JSON «_sum_received_» и «_sum_sent_» будут добавлены в сводку UDP _end_ как на сервере, так и на клиенте. Этот раздел не заменяет раздел _sum_.
2. «_Sum_received_» будет включать ненулевые данные только от получателя. Например, клиент установит его, когда используется -R или двунаправленный, но установит ноль, когда используется только отправитель.
3. "_sum_sent_" будет установлено с использованием аналогичных правил, но для отправителя или двунаправленного.

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