Определение асимметричных задержек в сети
https://stackoverflow.com/questions/1942877
-
20-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Представьте, что у вас много кластеризованных серверов на многих хостах в гетерогенной сетевой среде, так что соединения между серверами могут иметь сильно различающиеся задержки и пропускную способность.Вы хотите построить карту соединений между серверами путем передачи данных между ними.
Конечно, эта карта может устареть со временем по мере изменения топологии сети - но давайте пока проигнорируем эти сложности и предположим, что сеть относительно статична.
Учитывая задержки между узлами в этом графе хостов, вычисление пропускной способности является относительно простым временным упражнением.Однако у меня больше трудностей с задержками.Чтобы получить время прохождения туда и обратно, достаточно просто синхронизировать пинг обратной передачи с локального хоста на удаленный хост - оба события синхронизации (start, stop) происходят на локальном хосте.
Что, если мне нужно время в одну сторону, исходя из предположения, что задержка не одинакова в обоих направлениях?Предполагая, что часы на разных хостах не синхронизированы точно (по крайней мере, что их ошибка имеет ту же величину, что и соответствующие задержки) - как я могу вычислить одностороннюю задержку?
В связанном вопросе - является ли эта асимметричная задержка (когда ссылка быстрее в направлении, чем другая) распространенной на практике?По каким причинам / конфигурациям оборудования?Конечно, я знаю о сценариях асимметричной полосы пропускания, особенно на каналах связи последней мили, таких как DSL и кабельное телевидение, но я не так уверен в задержке.
Добавленный: После рассмотрения приведенного ниже комментария, вторую часть вопроса, вероятно, лучше оставить на ошибка сервера.
Решение
Насколько мне известно, асимметричные задержки - особенно асимметрии "последней мили" - не могут быть определены автоматически, потому что на любой протокол синхронизации сетевого времени в равной степени влияет одна и та же асимметрия, поэтому у вас нет точки отсчета, с которой можно оценить асимметрию.
Если бы у каждой конечной точки были, например, свои собственные GPS-часы, то у вас была бы ориентир для работы.
В Быстрое измерение параметров logP для платформ передачи сообщений, авторы отмечают, что для измерения задержки требуется синхронизация часов, внешняя по отношению к измеряемой системе.(Выделено жирным шрифтом мое, курсив в оригинальном тексте.)
Асимметричная задержка может быть измерена только путем отправки сообщения с меткой времени ts, и позволяя получателю извлекать задержку из tr - тs, где tr это время приема.Это требуется синхронизация часов между отправителем и получателем.Без внешний синхронизация часов (например, с помощью GPS-приемников или специализированного программного обеспечения, такого как протокол сетевого времени, NTP), часы могут быть синхронизированы только до детализация времени в оба конца между двумя хостами [10], что бесполезно для измерения задержки в сети.
Однако ни один сетевой алгоритм (такой как NTP) не устранит проблемы со связью последней мили, поскольку каждый ввод в алгоритм сам по себе будет равномерно зависеть от характеристик производительности линии последней мили и, следовательно, не будет "внешним" в приведенном выше смысле.(Я уверен, что можно построить доказательство, но у меня нет времени на его построение прямо сейчас.)
Другие советы
Специально для решения этой проблемы существует проект под названием One-Way Ping (OWAMP).Активность можно увидеть в LKML по добавлению временных меток высокого разрешения к входящим пакетам (SO_TIMESTAMP, SO_TIMESTAMPNS, и т.д.), чтобы помочь в расчете этой статистики.
http://www.internet2.edu/performance/owamp/
Есть даже версия Java:
Обратите внимание, что временная метка пакета действительно нуждается в аппаратной поддержке, и многие сетевые карты нынешнего поколения предлагают только миллисекундное разрешение, которое может быть не синхронизировано с часами хоста.В DDK есть статьи MSDN о синхронизации часов хоста и сетевой карты, демонстрирующие потенциальные проблемы.Временные метки в наносекундах от TSC проблематичны из-за различий в ядре и могут потребовать, чтобы архитектура Nehalem должным образом работала с требуемыми разрешениями.
http://msdn.microsoft.com/en-us/library/ff552492 (v=VS.85).aspx
Вы можете измерить асимметричную задержку по ссылке, отправив пакеты разного размера на порт, который возвращает пакет фиксированного размера, например, отправьте несколько udp-пакетов на порт, который отвечает сообщением об ошибке icmp.Сообщение об ошибке icmp всегда имеет одинаковый размер, но вы можете настроить размер отправляемого udp-пакета.
видишь http://www.cs.columbia.edu/techreports/cucs-009-99.pdf
В отсутствие синхронизированных часов асимметрия не может быть измерена, как доказано в статье 2011 года "Fundamental limits on synchronizing clocks over networks".
