RFC 3393 предназначен для измерения дисперсии в задержке пакета, а не для измерения самой задержки.
В качестве примера: вы пишете приложение для потоковой передачи видео. Вы хотите буферизовать как можно меньше видеоданных (чтобы воспроизведение началось как можно скорее). Предположим, что для данных всегда всегда всегда требуется 20 мс, чтобы добраться от машины A к машине B. В этом случае (и при условии, что машина A может отправлять видеоданные настолько быстро, насколько это необходимо для воспроизведения), вам не нужно нужен какой-то буфер вообще. Как только вы получите первый кадр, вы можете начать воспроизведение, зная, что к тому моменту, когда потребуется следующий кадр, он прибудет (потому что для получения данных всегда требуется ровно 20 мс, а машина A отправляет по крайней мере как быстро, как вы играете).
Это работает независимо от того, как долго эти 20 мсек, если они всегда одинаковы. Это может быть 1000 мсек - первый кадр занимает 1000 мсек, чтобы прибыть, но вы все равно можете начать воспроизведение, как только он прибудет, потому что следующий фрейм также займет 1000 мс и был отправлен сразу за первым фреймом - другими словами, он уже находится на его путь и будет здесь на мгновение. Очевидно, что реальный мир не такой.
Возьмите другую крайность: большую часть времени данные поступают через 20 мс. За исключением иногда, когда это занимает 5000 мс. Если у вас нет буфера и задержка на кадрах с 1 по 50 составляет 20 мс, тогда вы можете воспроизвести первые 50 кадров без проблем. Затем для кадра 51 требуется 5000 мс, и вы останетесь без видеоданных на 5000 мс. Пользователь заходит и посещает другой сайт со своими симпатичными кошачьими видео. Что вам действительно нужно, так это буфер 5000 мс данных - тогда все будет в порядке.
Длинный пример, короткая точка: вас не интересует, какова абсолютная задержка пакетов, вас интересует, какова дисперсия в этой задержке - это насколько большим должен быть ваш буфер.
Чтобы измерить абсолютную задержку, вам нужно синхронизировать часы на обеих машинах. Машина A отправит пакет с отметкой времени 12337849227 28 , и когда он прибудет на машину B в момент времени 12337849227 48 , вы узнаете, что для его получения понадобилось 20 мс.
Но поскольку вас интересует дисперсия , вам нужно (как описано в RFC 3393) несколько пакетов с машины A. Машина A отправляет пакет 1 с отметкой времени 1233784922 72 8, затем через 10 мс отправляет пакет 2 с отметкой времени 1233784922 73 8, затем через 10 мс отправляет пакет 3 с отметкой времени 1233784922 74 8.
Машина B получает пакет 1 с отметкой времени 1233784922 12 8. В этом случае задержка в одном направлении между машиной A и машиной B (с точки зрения машины B) составляет -600 мс. Это явно полная чушь, но нам все равно. Машина B получает пакет 2 с отметкой времени 1233784922 15 8. Задержка в одну сторону составляет -580 мс. Машина B получает пакет 3 с отметкой времени 1233784922 16 8. Задержка в одну сторону снова составила -580 мс.
Как и выше, нас не волнует, что такое абсолютная задержка - поэтому нам даже не важно, отрицательна она, три часа или что-то еще. Мы заботимся о том, чтобы величина задержки варьировалась на 20 мс. Таким образом, вам нужен буфер 20 мс данных.
Обратите внимание, что здесь я полностью закрываю вопрос о смещении часов (то есть, часы на машинах A и B работают с немного разными частотами, так что, например, время машины A увеличивается со скоростью 1,00001 секунды для каждого второе что на самом деле прошло). Хотя это вносит неточность в измерения, его практический эффект вряд ли будет проблемой в большинстве приложений.