Самый простой способ сделать это - отправить данные с устройства через тестируемую сеть, а затем снова получить их на том же устройстве.
Это позволяет легко рассчитать время, затрачиваемое на каждый пакет (задержку), разницу во времени для разных пакетов (дрожание), и обнаружить потерю любого пакета. Обратите внимание, что потеря пакета является относительной вещью - пакет может быть просто задержан на долгое время, а не потерян. Обычно, если пакет не получен в определенном окне дрожания, он может быть объявлен потерянным.
В реальном мире вы обычно хотите провести тестирование из точки «А» в точку «В» (т. Е. Не просто вернуться назад к точке «А»). Для речевого или видеокодека (кодера), который отправляет пакеты с регулярным интервалом, это просто, поскольку вы знаете, что второй пакет должен прибыть через определенный промежуток времени после первого, а если нет, он задерживается (или прибыл рано). Из этого вы можете рассчитать джиттер в точке «B». Любой пакет, который не прибывает (в течение периода, который вы позволяете пакетам прибыть), будет засчитан как потерянный пакет. Обратите внимание, что способ кодирования образца может вызвать проблемы с вычислением джиттера, хотя, если вы создаете тестовое приложение, в котором вы сами управляете кодированием, вы можете избежать этих проблем - для получения дополнительной информации см. Ссылку ниже: http://www.cs.columbia.edu/~hgs/rtp/faq.html#jitter
Еще одна вещь, которую следует отметить, это то, что вы не упомянули задержку, но она может быть очень важной, поскольку у вас может быть сеть без потери пакетов и отличного дрожания, но с большой задержкой, и это может оказать существенное влияние на некоторые приложения. (например, голос). В качестве простого и не очень реалистичного примера, скажем, у вас есть идеальная сеть с точки зрения дрожания и потери пакетов, но с маршрутизатором, который выполняет какой-то поиск безопасности и, следовательно, добавляет задержку в две секунды к каждому пакету. Поскольку для каждого пакета будет одинаковая задержка, ваш джиттер будет нормальным, но для двухстороннего голосового приложения основной проблемой будет задержка в две секунды между тем, кто говорит в точке «А», и кем-то в точке «Б». 1008 *