Сравнение tick-to-trade задержек CEPappliance и Solarflare TCPDirect

    В этой статье мы приводим значения задержек, измеренных для двух типов окружений — устройство на основе FPGA CEPappliance (“железка”) и компьютер с сетевой платой Solarflare в режиме TCPDirect, рассказываем как мы эти замеры получили — описываем методику измерения и ее техническую реализацию. В конце статьи есть ссылка на GitHub с полученными результатами и некоторыми исходниками.

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

    Методика измерения: что и как мы измеряли


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

    Схема измерительного стенда


    SUT (System Under Test) — либо CEPappliance, либо сервер с Solarflare (характеристики тестируемых систем см. ниже).

    У CEPappliance и Solarflare есть общая сфера применения — высокочастотный и алгоритмический трейдинг. Поэтому мы взяли за основу сценарий из этой сферы, измеряя величину задержки от момента отправки тестовым драйвером последнего байта пакета с рыночными данными (tick) до момента получения им первого байта пакета с заявкой (trade) на биржу (задержка MAC и PHY уровней драйвера одинакова для обоих тестовых сред и вычтена из результирующих значений, приведенных ниже) — так называемая задержка tick-to-trade. Замеряя время от момента отправки драйвером последнего байта, мы исключаем влияние скорости приема/передачи данных, завясящую от физического уровня.

    Измерять задержку можно и по другой методике — как время от момента отправки драйвером первого байта до момента получения им первого байта от измеряемой системы. Такая задержка будет больше и может быть расчитана на основе наших измерений по формуле:

    latency1-1 = latencyN-1 + 6.4 * int((N + 7) / 8),

    где latencyN-1 — измеренная нами задержка (от момента отправки драйвером последнего байта до момента получения им первого байта), N — длина Ethernet фрейма в байтах, int(x) — преобразование к целому, отбрасываением дробной части вещественного числа.

    Вот схема обработки, время выполнения которой составляет интересующую нас задержку:

    Схема обработки

    Что из себя представляют стадии тестирования?

    Подготовка:

    • Входные данные — записанный дамп потока заявок с торговой системы АСТС Московской биржи в виде сообщений, упакованных по протоколу FAST и передаваемых по UDP
    • Данные загружаются в память тестового драйвера с помощью утилиты

    Тестирование:

    • Тестовый драйвер
      • отправляет записанные UDP пакеты (проигрывает дамп) с рыночными данными — информацией о заявках (orders) на покупку или продажу, принятых биржей; информация включает действие с заявкой — добавление новой заявки, изменение или удаление ранее добавленной заявки, идентификатор торгуемого финансового инструмента, цена покупки/продажи, количество лотов и т.п.;
      • в одном пакете может содержаться информация об одной или нескольких заявках (после изменений в правилах упаковки данных, выпущенных биржей в марте 2017 года, мы встречали пакеты с информацией по 128-и заявкам!);
      • запоминает время отправки пакета T1.
    • Тестируемая система
      • принимает пакет с информацией о заявках;
      • распаковывает ее согласно заданным биржей правилам упаковки (сообщение X-OLR-CURR потока Orders с валютного рынка Московской биржи);
      • обновляет свою внутреннюю книгу заявок (“стакан”), применяя все данные из полученного пакета;
      • если лучшая (самая низкая) цена на продажу в книге изменилась, отправляет заявку на покупку с этой ценой по протоколу FIX.
    • Тестовый драйвер
      • получает TCP пакет с заявкой;
      • фиксирует время получения T2;
      • вычисляет задержку (T2 -T1) и запоминает ее.
    • Тестирование выполняется на наборе из 90 000 пакетов с рыночными данными, на полученном наборе значений задержки вычисляются статистические величины (среднее, дисперсия, перцентили). Пакеты отправляются строго по очереди. После отправки пакета ждем ответа, либо истечение таймаута (если алгоритм не должен реагировать на этот пакет с рыночными данными). После этого отправляем следующий пакет и т.д.

    Обработка результатов тестирования:

    • Полученные средние значения задержки выгружаются из памяти тестового драйвера
    • Каждое значение задержки сохраняется вместе со значением размера пакета входных данных, для которого оно было измерено

    Стенд для Solarflare


    В качестве SUT выступает сервер с материнской платой Asus P9X79 WS, процессором Intel Core i7-3930K CPU @ 3.20GHz и сетевой картой SFN8522-R2 Flareon Ultra 8000 Series 10G Adapter, поддерживающей TCPDirect.

    Для этого стенда была написана С-программа, которая получает UDP пакеты через Solarflare TCPDirect API, разбирает их, строит книгу заявок, формирует и отправляет сообщение на покупку по протоколу FIX.

    Разбор сообщения, построение стакана формирование сообщения с заявкой закодированы “жестко” без поддержки каких-либо вариаций и проверок, чтобы обеспечить минимальную задержку. С кодом можно ознакомиться на GitHub.

    Стенд для “железки” CEPappliance


    В качестве SUT выступает CEPappliance или “железка”, как мы ее называем, — это плата DE5-Net с FPGA чипом Altera Stratix V, вставленная в PCIe слот сервера, через который она получает питание и больше ничего. Управление и обмен данными с платой осуществляется через 10G Ethernet подключение.

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

    Программа сценария для CEPappliance содержится в двух файлах. В одном файле программа логики обработки данных, которую мы называем схемой. В другом файле описание адаптеров, через которые схема (или “железка” ее выполняющая) взаимодействует с внешним миром. Вот так просто!

    Для CEPappliance мы реализовали две версии схемы и для каждой версии сделали замеры. В одной версии (CEPappliance ALU) логика реализована на встроенном языке высокого уровня (см. строки 47-67). В другой (CEPappliance WIRE) — на Verilog’е (см. строки 47-54).

    Результаты


    Измеренные значения tick-to-trade задержки в наносекундах:
    SUT min avg max stddev 95% 97% 99% 99,9%
    Solarflare TCPDirect 1411 1637 2638 150 2022 2116 2303 2619
    CEPappliance ALU 1050 1125 1620 45 1251 1320 1415 1549
    CEPappliance WIRE 561 640 1163 45 768 825 907 1087

    Результаты измерений


    Выводы


    Чуда не произошло и “железка”, реализованная на основе FPGA, оказалась быстрее, чем решение на основе сервера с Solarflare TCPDirect. Чем выше перцентиль, тем заметнее разница в скорости. Одновременно с этим скорость работы решения на CEPappliance имеет дисперсию на порядок ниже.

    Вариант для CEPappliance, когда логика обработки данных реализована на Verilog, быстрее на 60-70%, чем реализация того же алгоритма на встроенном языке CEPappliance.

    Исходный код


    Мы разместили почти весь исходный код, участвовавший в тестировании, открытым на GitHub в этом репозитории.

    Закрытым оставили только код тестового драйвера, так как есть надежда его монетизировать. Ведь​ ​ он​ ​ позволяет​ ​очень точно измерить скорость реакции системы. А без этой информации сделать качественное HFT-решение почти невозможно.

    Что дальше?


    Было бы логично выяснить имеет ли значение выявленная разница в задержках различных решений, например, при торговле на Московской бирже. Про это будет в следующей статье. Но забегая вперед, скажем, что даже полмикросекунды имеет значение!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 10

      +1
      Если это не коммерческая информация:
      1. А на какой частоте удалось запустить основной алгоритм обработки в Stratix V?
      2. В вашей реализации скорость реакции в тактах всегда одинаковая или переменная?

      Эти вопросы возникли после указания точности в 1нс (в том числе) для FPGA реализации.
      Видится, что точность измерений должна быть грубее и зависеть от тактовой частоты, которая уж точно не может быть 1ГГц для FPGA.
        0
        1. Мы не разглашаем эту информацию.
        2. Скорость реакции переменная, так как во входящем сообщении может быть переменное число обновлений стакана.

        Один такт составляет какое-то не круглое число наносекунд. Количество тактов — тоже не круглое число. Одно на другое и дает нам число с единицами наносекунд.
        0
        Сроки и стоимость реализации проверок (логики?), а также скорость их работы, зависят от сложности проверок и того, кто их будет реализовывать. Не существует обобщенной адекватной оценки.

        Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
          0
          Сколько времени и денег необходимо для добавление проверок во всех трех случаях?
          На сколько ухудшится результат (99%)?
          Какова стоимость решение Solarflare TCPDirect по отношению к CEPappliance?

          Кмк, сейчас иметь очень быструю стратегию не достаточно для успешной торговли. Необходимо что бы стратегия была еще и умной. Профит в 1-2 микро пока не очевиден.
            0
            Сроки и стоимость реализации проверок (логики?), а также скорость их работы, зависят от сложности проверок и того, кто их будет реализовывать. Не существует обобщенной адекватной оценки.

            Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
            0
            Выбор DE5-Net для реализации обоснован субъективным опытом работы с Altera?
            Или объективно сравнивали характеристики с вариантами от Xilinx на тот момент?

            Мне также (субъективно) удобней в целом решения от Intel(Altera), но интересно почему в основном подобные решения для HFT делают на платах/ПЛИС Xilinx.

              0
              Да, у нас опыта работы с Altera больше. Мы хорошо знаем сильные и слабые стороны их чипов/плат/софта. Хотя Xilinx, по нашим оценкам, несколько дешевле, мы предпочли не менять проверенного в бою коня.
              0
              А чем задержку измеряли (с наносекундной точностью)? Я не заметил этого в статье.

              Из того, что у меня на столе лежит, ничего лучше чем ±4нс не даёт.
                0
                С помощью тестового драйвера — FPGA платы со специальной прошивкой. Его функции в статье описаны.
                  0
                  А клоксорс у вас там какой? отсечка по first byte/last byte? с измерением времени (особенно в районе нано и даже десятков наносекунд) всё сложно бывает.

                  Лучше всего округлять и писать погрешность измерения в таких случаях.

              Only users with full accounts can post comments. Log in, please.