Определите асимметричные задержки в сети
Предположите, что у Вас есть много кластеризованных серверов, через многие хосты, в среде неоднородной сети, такой, что соединения между серверами могут иметь дико переменные задержки и пропускную способность. Вы хотите создать карту соединений между серверами путем передачи данных между ними.
Конечно, эта карта может стать устаревшей со временем как изменения топологии сети - но позволяет, игнорируют те сложности на данный момент и предполагают, что сеть относительно статична.
Учитывая задержки между узлами в этом графике хоста, вычисляя пропускную способность родственник, просто синхронизирующий осуществление. Я испытываю больше трудностей с задержками - как бы то ни было. Для получения круговой задержки это - простой вопрос синхронизации ping обратной поездки от локального хоста до удаленного хоста - оба события синхронизации (запустите, остановитесь), происходите на локальном хосте.
Что, если я хочу односторонние времена под предположением, что задержка не равна по обоим направлениям? Предположение, что часы на различных хостах точно не синхронизируются (по крайней мере, что их ошибка имеет та же величина как включенные задержки) - как я могу вычислить одностороннюю задержку?
В связанном вопросе - эта асимметричная задержка (где ссылка более быстра в направлении, чем другой), распространенный на практике? Поскольку, что причины/аппаратные конфигурации? Конечно, я знаю об асимметричных сценариях пропускной способности, особенно на потребительских ссылках последней мили, таких как DSL и Кабель, но я не так уверен в задержке.
Добавленный: После рассмотрения комментария ниже, вторая часть вопроса, вероятно, более обеспечена на serverfault.
1 ответ
Насколько мне известно, асимметричные задержки - особенно асимметрии «последней мили» - не могут быть определены автоматически, потому что любой протокол синхронизации сетевого времени в равной степени подвержен такой же асимметрии, поэтому вы нет точки отсчета для оценки асимметрии.
Если бы каждая конечная точка имела, например, свои собственные часы GPS, то у вас была бы точка отсчета для работы.
В Быстрое измерение параметров LogP для платформ передачи сообщений авторы отмечают, что для измерения задержки требуется синхронизация часов, внешняя по отношению к измеряемой системе. (Полужирный шрифт выделен мной, курсив в исходном тексте.)
Асимметричная задержка может быть измерена только путем отправки сообщения с отметкой времени t s и предоставления получателю возможности получить задержку из t r - t s , где t r - время приема. Это требует синхронизации часов между отправителем и получателем. Без внешней синхронизации часов (например, с использованием GPS-приемников или специализированного программного обеспечения, такого как сетевой протокол времени , NTP), часы могут быть синхронизированы только с точностью до времени приема и передачи между двумя хостами [10], что бесполезно для измерения задержки в сети.
Ни один сетевой алгоритм (например, NTP) не устранит проблемы со связью последней мили, поскольку каждый вход в алгоритм сам будет одинаково зависеть от характеристик производительности последнего. миля и поэтому не является «внешним» в указанном выше смысле. (Я уверен, что можно построить доказательство, но у меня нет времени на его создание прямо сейчас.)