Высокоточная синхронизация времени для измерения задержки в ethernet сетях



На Хабре уже была заметка о том, как работает PTPv2. Я же собираюсь рассказать о том, как и для чего данный метод высокоточной синхронизации был реализован в наших приборах.

Для чего это надо


Я работаю в российской компании НТЦ-Метротек, которая разрабатывает и выпускает кучу всякой аппаратуры (свичи, тестеры, балансировщики и т.д.) для систем связи, в том числе и тестеры для ethernet-сетей. Например, вот такой. Одним из параметров, измеряемых этим прибором, является задержка прохождения пакета в тестируемой сети. Ха, скажет читатель Хабрахабра — задержку можно и ping'ом померить. Так-то оно и есть, но при разной загруженности сети может быть разная задержка. Наш прибор может измерять задержку с точностью до нескольких наносекунд и при этом создавать нагрузку до 10 Гб/с.

Для измерения задержки в каждый пакет, генерируемый анализатором, вставляется метка времени, а при приёме этого пакета определяется разность между текущим временем и данными из метки. Эта разность и есть задержка. Но так как обычно трафик от анализатора идет до специального устройства (шлейф), которое заворачивает этот трафик обратно к тестеру, то измеренная задержка является суммой времени прохождения пакетов от тестера к шлейфу (upstream) и от шлейфа к тестеру (downstream). Если канал симметричный, то есть его параметры равны в обоих направлениях, то задержку в одном направлении можно получить просто поделив измеренное значение на два.



В случае, когда канал не симметричный, надо измерять задержку отдельно в каждом из направлений. При этом используются два анализатора. Один генерирует тестовый трафик, второй его принимает и анализирует.



Тут-то и потребовалась высокоточная синхронизация времени, так как для корректного определения задержки необходимо, чтобы счетчики времени на обоих приборах имели одинаковое значение.

Как реализовано у нас


Упрощенную схему нашего прибора можно представить в следующем виде:



За отсчет времени отвечает FPGA, на ней реализован счетчик времени, работающий от частоты 125 МГц (отсюда и точность 8 нс). Счетчик времени может отличаться от эталонных часом смещением т.е. либо отставать, либо спешить на какое-то константное значение. Также может отличаться скорость изменения, то есть за секунду идеальный счетчик отсчитает 1*10^9 наносекунд, а реальный может насчитать либо больше, либо меньше, в результате чего смещение постоянно или увеличивается, или уменьшается. Для корректировки этих ошибок в FPGA реализована следующая схема:



Текущее значение счетчика можно изменить на заданную величину при помощи регистра offset. Для плавной подстройки используется дополнительный счетчик, при достижении им заданного значения (drift) счетчик времени либо пропускает один такт, либо вместо 1 увеличивается на 2. Т.е. если задать 10, то за десять тактов счетчик времени изменится на 11, за 20 тактов на 22 и т.д. Если задано отрицательное число, например -10 то за 10 тактов счетчик времени изменится на 9, за 20 тактов на 18 и т.д.

В нашем приборе используется сетевой стек операционной системы NutOs, работающей на 8-ми битном микроконтроллере avr-atmega2561. И если учитывать, что на этом микроконтроллере крутятся ещё много других задач, а работает он на 8 МГц, то становится понятно, что производительность данной системы крайне мала. Поэтому ту часть действий, которая требует высокой точности, выполняет FPGA, а на микроконтроллере реализована только логика протокола PTPv2.

Если посмотреть на диаграмму обмена, то видно, что при реализации PTPv2 клиента (Slave) надо точно знать время, когда приходит пакет от сервера (t2) и время, когда был отправлен ему ответ(t3).



Для этих целей мы модифицировали в FPGA MAC-ядро. При приеме сетевых пакетов к каждому из них добавляется метка времени (t2). А при отправлении пакетов текущее значение счетчика времени (t3) помещается в специальный регистр. На основании этих значений микроконтроллер и рассчитывает текущее рассогласование времени между эталонным источником и прибором.

Для проверки нашей реализации в качестве сервера PTPv2 мы сначала использовали обычный компьютер, на котором был запущен демон ptpd. Чтобы демон мог работать с PTP поверх ethernet (по умолчанию от работает только поверх UDP), надо надо разрешить работу с libpcap. Для этого при конфигурировании надо задать ключ -with-pcap-config.

При запуске ptpd надо указать конфигурационный файл, например, вот такой:

ptpengine:interface = eth0
ptpengine:preset = masteronly
ptpengine:transport = ethernet
ptpengine:use_libpcap = Y
ptpengine:delay_mechanism = E2E


Для начала решили посмотреть, как будут расходиться счетчики времени на компьютере и приборе, если не делать подстройку частоты.



Видно, что зависимость почти линейная, за секунду счетчик на приборе убегает вперед на двадцать с лишним микросекунд.

Затем вычисленное значение рассогласования стали записывать в регистр корректировки смещения (offset):



По этому графику также видно, что в среднем за секунду набегает ошибка около 22 микросекунд. Использовать подстройку при помощи смещения не очень хорошо, так как при этом происходит скачкообразное изменение счетчика, а так как это изменение происходит асинхронно на двух приборах, то это может приводить к большим ошибкам при измерении задержки. Лучше воспользоваться плавной подстройкой частоты, записать в регистр drift, такое значение, что бы счетчик в FPGA корректировался на 22 микросекунды за одну секунду.

Для автоматической подстройки реализовали ПИ регулятор. Для интегральной составляющей установили коэффициент равный 0.01 а для пропорциональной 0.05.

С ним зависимость рассогласования от времени выглядит так:



Видно, что рассогласование «шумит» и достигает 20 и более микросекунд. Это не удивительно, ведь в качестве PTP сервера используется обычный компьютер.

Когда мы проверили нашу реализацию с сервером точного времени Метроном-50, в котором реализована аппаратная поддержка PTP, то получили рассогласование величиной в десятки наносекунд, что вполне достаточно для корректного измерения задержки в асимметричном канале.



Выводы


Если задержка в тестируемом канале измеряется в миллисекундах, то в качестве PTP-сервера можно использовать обычный компьютер с демоном ptpd. Если же задержка в сети несколько микросекунд, то без сервера с аппаратной поддержкой PTP не обойтись.
  • +23
  • 17,2k
  • 3
НТЦ Метротек 57,18
Разработка и производство Ethernet устройств etc.
Поделиться публикацией
Похожие публикации
Комментарии 3
  • 0
    Интересно, но ведь есть же флюк, у которого цена тысяч на 30 ниже, чем у беркута. В чем преимущество над флюком?
    • +1
      Мне кажется, что сравнивать абстрактные «флюк» и «беркут» не совсем корректно. Скажите, пожалуйста, про какую модель «флюк» Вы говорите, и с каким «беркутом» сравниваете. Какие опции в комплекте были у «флюк» и у «беркута»?
      Например OPVXG-LAN-10G стоит 38000$. Точную цену на Беркут-ETX я не знаю, но, по моему она в разы меньше.
      • +1
        По-правде говоря оставил это на усмотрение автора статьи, потому что поленился разбираться в деталях спецификации и предполагал что автор укажет на прямых конкурентов.

        Но раз вопрос задан — очевидно что OPVXG-LAN-10G превосходит тот же ETX по функционалу — там один анализ беспроводных сетей чего стоит. Ну и собственно назначение флюка — анализ сети (начиная от того же маркированного трафика, заканчивая готовыми решениями для специалиста по проблемам с коммутацией и умершим свитчам), тут ЕТХ всё что предлагает — это генерация маркированного трафика, регистрация трафика и задержка.

        Согласен, с ценой я промахнулся (на сайте беркута нет её, к сожалению, пришлось спрашивать на мейл-ру-ответах), но если не рассматривать только со стороны стоимости, а в целом — польза для компании. В общем, хотелось бы услышать мнение автора о конкурентах.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое