Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Ну так стоплоссы надо ставить.
меня всегда интересовало как ведется отладка и настройка таких программ? На живой системе слишком дорого, на модели — слишком неправдоподобно.
Можно запустить такую программу в живой системе так, чтобы она имела к ней полный доступ на чтение, но все изменения были бы «виртуальными». В таком случае программа не создает опасности на реальных торгах, но её деятельность можно оценить.
Однако, реально работающая в сети программа вносит изменения в саму систему. Не работающая — не вносит. Согласно принципам динамического хаоса, внесенные в систему изменения (даже небольшие) могут в итоге в процессе эволюции системы привести ее довольно далеко от той точки в фазовом пространстве, которая бы отвечала состоянию системы, если бы тех малых изменений не было бы внесено.
Потому такая программа хотя и полезна, но в итоге «работает» с биржей, которая НЕ будет существовать после внесения в нее изменений. Будет показывать точные выходные данные лишь при малом приближении (по суммам сделок), а по мере увеличения суммы сделок будет возрастать и влияние на систему и расхождение будет расти и расти.
Потому такая программа хотя и полезна, но в итоге «работает» с биржей, которая НЕ будет существовать после внесения в нее изменений. Будет показывать точные выходные данные лишь при малом приближении (по суммам сделок), а по мере увеличения суммы сделок будет возрастать и влияние на систему и расхождение будет расти и расти.
Можно у биржи попросить открыть виртуальный депо и на нем настраивать. Фид котировок/информация в этом случае 1 в 1 как в реальности, разница лишь в формальной обработке ордеров, они исполняются на виртуальном депо, это не работа с деньгами. Но это, как правило, уже совсем последние этапы, после всех стрессов и т.п.
До этого это отладка в своих песочницах, либо при помощи спецсофта, либо свои.
До этого это отладка в своих песочницах, либо при помощи спецсофта, либо свои.
Именно таких сказать не возьмусь, но я например вначале гоняю на исторических данных, потом на тестовом контуре, который есть у ММВБ'шников, затем под чутким надзором, с дебагером, на маленьких денежных суммах, и только потом уже стратегия полноценно уходит в бой. Возможно они используют какие-то похожие методы.
А как вы с биржей выясняете отношения, если баг у них? Логи пишете, чтобы потом предъявить?
С багами шлюза на ММВБ не сталкивался, но были несколько раз проблемы с брокерами, которые делают свой пре-трейд перед шлюзом, так там да, логи от шлюза отправлял, шлюз сам их умеет вести, причем имеет на выбор несколько уровней детализации.
Но и саппорт на бирже конечно хорошо отвечает, когда что-нибудь требуется.
Но и саппорт на бирже конечно хорошо отвечает, когда что-нибудь требуется.
Спасибо большое за проделанный труд! Если Вас не затруднит, у меня возникло несколько вопросов:
1) Какова цель данной публикации? Исключительно личный интерес, и он связан именно с тем, о чем в статье было написано — подобного уровня работы практически не публикуют, по вполне понятным причинам.
2) Было ли подобное реализовано в реальном железе?
3) Я так понимаю, что подобные штуки в основном (не только, но) создаются для арбитража внутри спреда и основные алгоритмы основаны на этом узком классе задач, верно? Если нет — уточните пожалуйста для каких конкретно/примерно алгоритмов/методик это используется.
4) Ну и последнее, не сочтите за наглость, исключительно сами знаете что — если это сейчас работает, то на каких классах инструментов используется и хотя бы поверхностные цифры (к примеру — увеличение окна/вероятности иметь более выгодную цену и т.п.) чтобы понять целесообразность использования подобного в реальности.
Если это дипломная работа и суть в проверке теории, то в принципе вопросы можно снять. Еще раз спасибо!
1) Какова цель данной публикации? Исключительно личный интерес, и он связан именно с тем, о чем в статье было написано — подобного уровня работы практически не публикуют, по вполне понятным причинам.
2) Было ли подобное реализовано в реальном железе?
3) Я так понимаю, что подобные штуки в основном (не только, но) создаются для арбитража внутри спреда и основные алгоритмы основаны на этом узком классе задач, верно? Если нет — уточните пожалуйста для каких конкретно/примерно алгоритмов/методик это используется.
4) Ну и последнее, не сочтите за наглость, исключительно сами знаете что — если это сейчас работает, то на каких классах инструментов используется и хотя бы поверхностные цифры (к примеру — увеличение окна/вероятности иметь более выгодную цену и т.п.) чтобы понять целесообразность использования подобного в реальности.
Если это дипломная работа и суть в проверке теории, то в принципе вопросы можно снять. Еще раз спасибо!
Специально уточню вопрос 2 — это устройство делалось с нуля по теории и спекам, либо было уже на что смотреть и
делали похожее? Если да и не секрет — где смогли подобное достать.
делали похожее? Если да и не секрет — где смогли подобное достать.
Простите, я не смогу ответить на ваши вопросы потому что это перевод статьи, которая показалась мне очень интересной.
Я знаю что в России подобная разработка тоже ведется, я видел как этим занимаются мои коллеги, тоже на FPGA, но с хостом общаются через PCI-Express, когда я с ними последний раз разговаривал, этот интерфейс был у них вроде как узким местом. Больше к сожалению сказать ничего не могу.
Я знаю что в России подобная разработка тоже ведется, я видел как этим занимаются мои коллеги, тоже на FPGA, но с хостом общаются через PCI-Express, когда я с ними последний раз разговаривал, этот интерфейс был у них вроде как узким местом. Больше к сожалению сказать ничего не могу.
Да, я в пылу переваривания темы поста и фиксации вопросов пропустил момент, что это перевод. Мой вопрос по большей части был с целью проверить, для чего КРОМЕ ловли внутриспредовых окон можно использовать столь временнО-заточенный инструмент. Пока со всем, с чем я сталкивался при использовании подобного — это практически всегда игра со временем и поиск этого окна с возможностью совершения безрисковой сделки внутри спреда. Потому как в иных случаях затраты на анализ и принятие решений все же требуют больше времени, чем время операционной обработки ордеров/получения фида котировок и подобные инструменты, как описаны в посте действительно будут лишь полезным дополнением, нежели определяющим (на мой взгляд). При арбитраже внутри спреда, к примеру, достаточно самого примитивного мат.анализа с очень простым механизмом оценки, потому в этих случаях главное — да, скорость, и она упирается явно не в алгоритм, а уже в передачу данных. Естественно, что все RM и MM предполагается что проводятся не чаще раза в минуту и остальные слои алгоритмов на время принятия решения существенно не влияют.
А с теорией и в некоторой степени практикой про вч-торговлю я знаком, просто хотел уточнить в ожидании необычного использования, чего-то нового.
А с теорией и в некоторой степени практикой про вч-торговлю я знаком, просто хотел уточнить в ожидании необычного использования, чего-то нового.
В статье они еще пишут что HFT используется для поиска ликвидности, то есть ищут айсберг-заявки, дарк-пулы, скрытые ордеры, но непонятно зачем это нужно.
То есть они шлют кучу мелких заявкок, «пингуют» стакан и т.д.
Если например трейдер обнаруживает большую скрытую заявку на покупку, он может встать перед этой заявкой по чуть более высокой цене, и если цена пойдет вверх — то он сможет заработать. Если же цена пойдет вниз, то он будет застрахован, потому что успеет быстро продать актив в стакане этому дарк-пулу практически без потерь, таким образом полностью контролирует риски.
То есть они шлют кучу мелких заявкок, «пингуют» стакан и т.д.
Если например трейдер обнаруживает большую скрытую заявку на покупку, он может встать перед этой заявкой по чуть более высокой цене, и если цена пойдет вверх — то он сможет заработать. Если же цена пойдет вниз, то он будет застрахован, потому что успеет быстро продать актив в стакане этому дарк-пулу практически без потерь, таким образом полностью контролирует риски.
Это перевод же
С такими задержками важным становится даже положение сервера в стойке… у кого кабель к маршрутизатору короче, того и тапки… или они стандартизированы?
Возможно, я чего-то не понимаю, но разве этот выигрыш в наносекунды не будет нивелирован кошмарно медленным исполнением на стороне брокера?
Кто бы еще лет 50 назад мог подумать, что лучшие умы будут брошены на поиск выигрыша в игре с нулевой суммой…
Откуда взялась оценка, что это решение улучшает результат в 4 раза?
Если используется более-менее адекватное железо (а другого для этих нужд обычно не используют), то время прохождения ваших запросов по сети и их обработки на trading-серверах будет на порядки больше, чем время реакции робота трейдера.
На схеме инфрастурктуры вы пишите Exchange WAN (я понимаю это как World Area Network). А это, как правило, ethernet пусть даже и гигабитный, который асинхронный по своей природе.
И трейдинг-сервера обрабатывают запросы вовсе не одного участника рынка. Там наверняка очередь запросов, которые обрабатываются в порядке поступления. Скорость реакции трейдинг-сервера на ваш запрос очень сильно зависит от нагрузки в конкретный момент времени. Говорить о каком-то реал-тайме там вообще не приходится…
Поэтому и по целому ряду других причин, я честно говоря позволю себе усомниться в оценке автора статьи.
Куда более эффективным на мой взгляд будет прямой стык с трейдинг-серверами например по Infiniband. Но это совсем другая песня…
Если используется более-менее адекватное железо (а другого для этих нужд обычно не используют), то время прохождения ваших запросов по сети и их обработки на trading-серверах будет на порядки больше, чем время реакции робота трейдера.
На схеме инфрастурктуры вы пишите Exchange WAN (я понимаю это как World Area Network). А это, как правило, ethernet пусть даже и гигабитный, который асинхронный по своей природе.
И трейдинг-сервера обрабатывают запросы вовсе не одного участника рынка. Там наверняка очередь запросов, которые обрабатываются в порядке поступления. Скорость реакции трейдинг-сервера на ваш запрос очень сильно зависит от нагрузки в конкретный момент времени. Говорить о каком-то реал-тайме там вообще не приходится…
Поэтому и по целому ряду других причин, я честно говоря позволю себе усомниться в оценке автора статьи.
Куда более эффективным на мой взгляд будет прямой стык с трейдинг-серверами например по Infiniband. Но это совсем другая песня…
Если сомневаетесь, вы можете написать ученым из University of Heidelberg, которые проводили данные исследования. Они смогут предоставить вам все необходимые доказательства тех оценок, которые были ими получены.
*промахнулся, это сюда
*промахнулся, это сюда
Подозреваю, это был грант, типа, «что-то наши компы очень медленно работают» от какого-нибудь спекулянта-миллиардера… Ребята это грант успешно отработали. Локальную обработку вполне может быть реально ускорили в 4 раза. А то, что это ничего принципиально не дает, и преимущество в 4 раза существует только у этого спекулянта в голове, просто тактично промолчали…
Зачем резать курицу, несущую золотые яйца…
Зачем резать курицу, несущую золотые яйца…
Очередное доказательство того, что люди готовы пойти на все, что бы делать деньги из воздуха.
Это ОЧЕНЬ странно! Ну, ладно, по какой-то причине мы считает, что современные ОС вносят заметные задержки. Но!
1) Есть RealTime — пишем под такое и получаем около-нулевые задержки обработки. Это самый вменяемый способ! Я готов спорить на что угодно, что такое решение на современном железе порвёт FPGA, как тузик- грелку. Причём можно в один потоках фоном обрабатывать какую-то не риел-тайм статистику, а в других — обрабатывать сетевой трафик. Хочет нулевые задержки? Да хоть в кольце 0 пиши — будет обработка сразу по приёму.
2) Что мешало написать это забацать это всё по под микроконтроллер (а они сейчас очень быстрые), где жёсткое реальное время и практически могут отсутствовать задержки на обработку? Там получил прерывание от сетевой карты и обрабатывай в реальном времени.
Нахрена там FPGA?!!!
1) Есть RealTime — пишем под такое и получаем около-нулевые задержки обработки. Это самый вменяемый способ! Я готов спорить на что угодно, что такое решение на современном железе порвёт FPGA, как тузик- грелку. Причём можно в один потоках фоном обрабатывать какую-то не риел-тайм статистику, а в других — обрабатывать сетевой трафик. Хочет нулевые задержки? Да хоть в кольце 0 пиши — будет обработка сразу по приёму.
2) Что мешало написать это забацать это всё по под микроконтроллер (а они сейчас очень быстрые), где жёсткое реальное время и практически могут отсутствовать задержки на обработку? Там получил прерывание от сетевой карты и обрабатывай в реальном времени.
Нахрена там FPGA?!!!
Ну, ладно, по какой-то причине мы считает, что современные ОС вносят заметные задержки
Для таких задач заметные. Да даже и не для таких задач тоже не менее заметные.
Есть RealTime — пишем под такое и получаем около-нулевые задержки обработки.
RealTime — это гарантия на время отклика. А задержки в RealTime могут измеряться и секундами и часами и даже большими промежутками времени. Главное — это успеть отработать строго до конкретного момента времени.
Я готов спорить на что угодно, что такое решение на современном железе порвёт FPGA, как тузик- грелку.
Не порвет. Измерения из статьи это наглядно подтверждают.
Там получил прерывание от сетевой карты и обрабатывай в реальном времени.
Именно это и мешало. Сетевая карта не самая быстрая штука, да и сетевой стек ОС тоже. Судя по статье авторы реализовали в FPGA и функционал сетевой карты и вообще весь специализированный сетевой стек, за счет чего и снизили задержки обработки.
Гхм… В обычных ОС задержки — мкиросекундные. По крайней мере а 1мС можно уложить и обработку и сетевой уровень. И это без RealTime. Но, да — гарантировать ничего нельзя — нужен тонкий тюнинг ОС.
RealTime — это возможно задать приоритеты. И если мы хотим, чтобы UDP обрабатывался сразу после получения, то мы это получим. «Успеть отработать» в контексте современного железа уже не вопрос. Вопрос лишь в работе планировщиков задач и сетевых стеков современных ОС. Но ОС реального времени эту проблему решает полностью.
"Измерения из статьи это наглядно подтверждают." Ничего они не подтверждают. Там изначально неверные подход.
"Особая природа FAST протокола, не позволяющая производить его эффективную обработку на стандартных CPU," только при работе на обычных ОС и без оптимизаций. FAST работает по верх UDP, который по-верх Ethernet PHY. И хоть тресни, но пока пакет не будет принят целиком, его обработка не начнётся. А когда он будет принят целиком, то его можно и CPU обрабатывать. Задержку вносят лишь сетевые стеки ОС и планировщик процессов.
"Именно это и мешало. Сетевая карта не самая быстрая штука, да и сетевой стек ОС тоже."
Уж простите, но что Вы несёте? Сетевая карта получает пакет и кладёт его в буфер ОЗУ в очередь пакетов. Задержки при этом околонулевые (время задержки измеряется единацми микросекунтд, а на некоторых картах — наносекундами). Их реализация сетевой карты на FPGA ровно ничем не отличается от обычной современной сетевой карты.
Со стеком — да. Современные сетевые стеки ОС общего назначения ориентированы не на минимизцию задержек, а на макимальную пропускную способность. Но, как я уже говорил:
1) Использовать систему реального времени, где можно задать максимальный приоритет обработке сетевого стека.
2) Мы работаем с UDP — это минимальный оверхед поверх физического уровня. Все современные сетевые карты умеют аппаратно обрабатывать IP/UP и даже TCP. Зачем изобретать велосипед? Если очень хочется, то никто не запрещается написать фильтр драйвера сетевой карты и работать вообще без сетевого стека. И никаких задержек. Вообще никаких. Вплоть до того, что современные карты имеют zero-copy приём пакетов и мы их даже копировать не будем — будем сразу получать готовый (проверенный сетевой картой) пакет.
Короче, стек для UDP не обязателен и даже в обычных ОС можно работать без него, избежав задержек.
В общем — зачем?! Есть промышленные системы на основе для жёсткого реального времени, где все эти задачи уже решены.
И ещё один момент — сколько занимает обработка пакета даже в обчыной (не РВ) ОС? Если стоит современная сетевая карта с аппаратной обработкой UDP, ОС настроена, программа правильно написана — вы не поверите — ни как не более 100 мкС. А сколько вносить каждый маршрутизатор от нас до источника котировок? Тоже примерно 100 мкС. Каждый! В лучшем случае! Какая, блин, FPGA?! У нас среда распространения и её нестабильно больше влияет!
RealTime — это возможно задать приоритеты. И если мы хотим, чтобы UDP обрабатывался сразу после получения, то мы это получим. «Успеть отработать» в контексте современного железа уже не вопрос. Вопрос лишь в работе планировщиков задач и сетевых стеков современных ОС. Но ОС реального времени эту проблему решает полностью.
"Измерения из статьи это наглядно подтверждают." Ничего они не подтверждают. Там изначально неверные подход.
"Особая природа FAST протокола, не позволяющая производить его эффективную обработку на стандартных CPU," только при работе на обычных ОС и без оптимизаций. FAST работает по верх UDP, который по-верх Ethernet PHY. И хоть тресни, но пока пакет не будет принят целиком, его обработка не начнётся. А когда он будет принят целиком, то его можно и CPU обрабатывать. Задержку вносят лишь сетевые стеки ОС и планировщик процессов.
"Именно это и мешало. Сетевая карта не самая быстрая штука, да и сетевой стек ОС тоже."
Уж простите, но что Вы несёте? Сетевая карта получает пакет и кладёт его в буфер ОЗУ в очередь пакетов. Задержки при этом околонулевые (время задержки измеряется единацми микросекунтд, а на некоторых картах — наносекундами). Их реализация сетевой карты на FPGA ровно ничем не отличается от обычной современной сетевой карты.
Со стеком — да. Современные сетевые стеки ОС общего назначения ориентированы не на минимизцию задержек, а на макимальную пропускную способность. Но, как я уже говорил:
1) Использовать систему реального времени, где можно задать максимальный приоритет обработке сетевого стека.
2) Мы работаем с UDP — это минимальный оверхед поверх физического уровня. Все современные сетевые карты умеют аппаратно обрабатывать IP/UP и даже TCP. Зачем изобретать велосипед? Если очень хочется, то никто не запрещается написать фильтр драйвера сетевой карты и работать вообще без сетевого стека. И никаких задержек. Вообще никаких. Вплоть до того, что современные карты имеют zero-copy приём пакетов и мы их даже копировать не будем — будем сразу получать готовый (проверенный сетевой картой) пакет.
Короче, стек для UDP не обязателен и даже в обычных ОС можно работать без него, избежав задержек.
В общем — зачем?! Есть промышленные системы на основе для жёсткого реального времени, где все эти задачи уже решены.
И ещё один момент — сколько занимает обработка пакета даже в обчыной (не РВ) ОС? Если стоит современная сетевая карта с аппаратной обработкой UDP, ОС настроена, программа правильно написана — вы не поверите — ни как не более 100 мкС. А сколько вносить каждый маршрутизатор от нас до источника котировок? Тоже примерно 100 мкС. Каждый! В лучшем случае! Какая, блин, FPGA?! У нас среда распространения и её нестабильно больше влияет!
Тьфу, блин, опечатался — обработка пакета ~100 нС.
Можно найти логику в ваших слов, но разве сетевая карта на PCI сможет в итоге записать в память процесса быстрее чем шина HyperTransport из статьи? Мне рассказывали парни которые делали подобные вещи, что у них ботлнек в шине PCI-E. Вот авторы как раз нашли решение в виде HT.
Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка.
А на микроконтроллере не сделали, они же написали, потому что протокол постоянно меняется, и как я понял на FPGA легче добиться гибкости, но это все допущения, так как сам такого не делал.
Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка.
А на микроконтроллере не сделали, они же написали, потому что протокол постоянно меняется, и как я понял на FPGA легче добиться гибкости, но это все допущения, так как сам такого не делал.
Что значит быстрее? На сколько? И почему PCI, а не PCI-E?
Если говорить только быстрее/медленнее, то да — их шина быстрее, но я не могут представить каким образом разница в 10 нС, может на что-то повлиять. Разброс в доставке данных от компьюетеров биржи до клиентов должен быть больше. Все почему-то забывают, что на ТОЙ стороне тоже стоит компьютер с ОС, базами данных, обычными сетевыми картами и каким количество маршрутизаторов/коммутаторов.
"Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка." Да, если используем обычную ОС и обычный сетевой стек. Что мешает обрабатывать данные непосредственно в ядре? Или даже в обработчике прерывания от сетевой карты? Для настольных ОС это конечно дикость, но для промышленных применений — норма. И не будет вообще никакой задержки — только на вход в обработчик прерывания, но это современных процессоров — единицы наносекунд.
На FPGA как раз чёрт ногу сломит — это же железо.
Я как бы могу понять, когда для торговли кладут отдельный прямой кабель по дну океана — кажется дикостью, но если посчитать, то да — время прохождения света между континентами в десятки--сотни раз больше времени обработки. Но что они экономят тут…
Точнее я о охотно верю, что эти хлопцы показывают большее быстродействие по сравнению с сетевой картой. Вопрос в том, на сколько более, и как эта цифра соотносится с остальными задержками. Если эта экономия времени в сто раз меньше, чем разброс времени распространения информации, то толк будет более чем сомнительный.
Мне кажется, что тут просто отличный способ выбить денег с инвесторов — вот смотрите, наша хреновина быстрее их хреновины. А кто и как мерил это «быстрее» и на сколько именно быстрее, можно не вдаваться.
Как бы ещё раз — на ТОМ конце обычный компьютер (и не один, а кластер) с обычной сетевой картой (пусть хорошей, ноне FPGA), с более-менее обычной ОС (ему же всю биржу обрабатывать!) и ещё каким-то сетевым оборудованием (там не один клиент, а целая биржа висит, вместе с IP стеком и массой всего для поддержания — нужно же ещё и отказоустойчивость обеспечить) — что на фоне всех этих огромных (по сравнению со временем приёма пакета) случайных задержек мы пытаемся сэкономить на ЭТОМ конце?
Если говорить только быстрее/медленнее, то да — их шина быстрее, но я не могут представить каким образом разница в 10 нС, может на что-то повлиять. Разброс в доставке данных от компьюетеров биржи до клиентов должен быть больше. Все почему-то забывают, что на ТОЙ стороне тоже стоит компьютер с ОС, базами данных, обычными сетевыми картами и каким количество маршрутизаторов/коммутаторов.
"Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка." Да, если используем обычную ОС и обычный сетевой стек. Что мешает обрабатывать данные непосредственно в ядре? Или даже в обработчике прерывания от сетевой карты? Для настольных ОС это конечно дикость, но для промышленных применений — норма. И не будет вообще никакой задержки — только на вход в обработчик прерывания, но это современных процессоров — единицы наносекунд.
На FPGA как раз чёрт ногу сломит — это же железо.
Я как бы могу понять, когда для торговли кладут отдельный прямой кабель по дну океана — кажется дикостью, но если посчитать, то да — время прохождения света между континентами в десятки--сотни раз больше времени обработки. Но что они экономят тут…
Точнее я о охотно верю, что эти хлопцы показывают большее быстродействие по сравнению с сетевой картой. Вопрос в том, на сколько более, и как эта цифра соотносится с остальными задержками. Если эта экономия времени в сто раз меньше, чем разброс времени распространения информации, то толк будет более чем сомнительный.
Мне кажется, что тут просто отличный способ выбить денег с инвесторов — вот смотрите, наша хреновина быстрее их хреновины. А кто и как мерил это «быстрее» и на сколько именно быстрее, можно не вдаваться.
Как бы ещё раз — на ТОМ конце обычный компьютер (и не один, а кластер) с обычной сетевой картой (пусть хорошей, ноне FPGA), с более-менее обычной ОС (ему же всю биржу обрабатывать!) и ещё каким-то сетевым оборудованием (там не один клиент, а целая биржа висит, вместе с IP стеком и массой всего для поддержания — нужно же ещё и отказоустойчивость обеспечить) — что на фоне всех этих огромных (по сравнению со временем приёма пакета) случайных задержек мы пытаемся сэкономить на ЭТОМ конце?
Давайте посмотрим на практике.
Есть порядка 500км оптики, и штук 10 коммутаторов (что, как минимум в 3 раза больше чем нужно, по этому лишние будут убраны переключением на другой канал). Запустим ping -c100:
Среднеквадратическое отклонение == 0.055 ms или 55мкс
А теперь проанализируем эту величину.
Начнем с того, что с одной стороны стоит десктопная сетевая карта от Intel. Во вторых опять-же огромное количество коммутаторов, среди которых есть очень старые.
А теперь самое главное! В этом-же канале идет пара сотен мегабит интернет-трафика, который влияет чуть менее чем непредсказуемым способом.
А теперь внимание вопрос: на сколько уменьшится разброс latency-канала, если из него убрать все лишнее и поставить серверное железо на второй конец? Вот и получим мы, что 8 мкс, которые выиграли авторы статьи уже сопоставимо со случайными задержками и есть смысл с ними побороться.
А если взять сеть биржи, то там и ресурсы доступные побольше будут, чем есть у меня.
Кстати на счет стабильности времени обработки заявок биржами ( www.opennet.ru/opennews/art.shtml?num=28362 ):
А в среднем, как я понимаю, порядка 30 мкс ( www.londonstockexchange.com/products-and-services/technical-library/technical-user-group/5july2011.pdf )
Есть порядка 500км оптики, и штук 10 коммутаторов (что, как минимум в 3 раза больше чем нужно, по этому лишние будут убраны переключением на другой канал). Запустим ping -c100:
rtt min/avg/max/mdev = 5.480/5.509/5.559/0.055 ms
Среднеквадратическое отклонение == 0.055 ms или 55мкс
А теперь проанализируем эту величину.
Начнем с того, что с одной стороны стоит десктопная сетевая карта от Intel. Во вторых опять-же огромное количество коммутаторов, среди которых есть очень старые.
А теперь самое главное! В этом-же канале идет пара сотен мегабит интернет-трафика, который влияет чуть менее чем непредсказуемым способом.
А теперь внимание вопрос: на сколько уменьшится разброс latency-канала, если из него убрать все лишнее и поставить серверное железо на второй конец? Вот и получим мы, что 8 мкс, которые выиграли авторы статьи уже сопоставимо со случайными задержками и есть смысл с ними побороться.
А если взять сеть биржи, то там и ресурсы доступные побольше будут, чем есть у меня.
Кстати на счет стабильности времени обработки заявок биржами ( www.opennet.ru/opennews/art.shtml?num=28362 ):
Утверждается, что при среднем времени операции в 126 микросекунд система позволит обслужить 99% заявок за общее время не превышающее 210 микросекунд и только 0.1% операций может занять более 400 микросекунд.
А в среднем, как я понимаю, порядка 30 мкс ( www.londonstockexchange.com/products-and-services/technical-library/technical-user-group/5july2011.pdf )
Пусть так. Но 126 микросекунд время операции. Как я уже говорил — на ОС реального времени или в режиме ядра можно можно получить время обработки <10мкС.
Я лично для промышленного применения получал гарантированное время реакции системы <1мкС — с приёмом, анализом пакета и ответом.На ОЧЕНЬ слабеньком железе. На хрена было городить огород с FPGA?
Я не спорю с тем, что обычная ОС может не подходить для такой торговли, я не согласен с тем, что современный 3 ГГц процессор с современной сетевой картой не может получить время такое время реакции такое, чтобы им можно было пренебречь. Вопрос может быть только в структуре программы, но она по-любому проще чем FPGA городить-отлаживать.
Я лично для промышленного применения получал гарантированное время реакции системы <1мкС — с приёмом, анализом пакета и ответом.На ОЧЕНЬ слабеньком железе. На хрена было городить огород с FPGA?
Я не спорю с тем, что обычная ОС может не подходить для такой торговли, я не согласен с тем, что современный 3 ГГц процессор с современной сетевой картой не может получить время такое время реакции такое, чтобы им можно было пренебречь. Вопрос может быть только в структуре программы, но она по-любому проще чем FPGA городить-отлаживать.
Как бы я вижу такой порядок цифр:
Если на нашем конце обрабатывать всё в обычной ОС, то время реакции будет 30..100 мкС (от момента, когда последний электрический импульс пакета попал в сетевую карту, то момента, когда сетевая карта начала передавать ответ).
Если извращаться с реальным временем, обработчиками прерываний и т.п., то время реакции будет 3-10 мкС. На FPGA можно добиться реального времени реакции ещё на порядок меньше — что-то порядка 1 мкС.
А теперь внимание.
После передачи наш ответный пакет пройдёт через несколько маршрутизаторов (биржа обслуживает тысячи клиентов).
Попадёт в сетевую карту сервера биржи и от туда в очередь пакетов буфера приёма (у них много клиентов и все что-то шлют). Наш пакет может быть в очереди первым, а может быть тысячным.
Дальше какей-то время нужно планировщику пакетов сервера, чтобы обработать другие задачи и запустить драйвер сетевой карты и обработчик стека TCP/IP.
Потом будут обработаны все пакеты из очереди.
Клиентов, как я говорил у биржи тысячи. Поток данных — огромный. Нужно ещё обеспечить надёжность. Теряется время на межпоточную синхронизацию. Нужно обеспечить надёжность — должен быть не один сервер, а несколько. Одновременно идут миллионы сделок — это всё тоже нужно обрабатывать. Нужно всё кидать в какую-то базу данных.
Чувствуете, как нарастает сложность и время обработки?
В общем, есть мнение, что ИХ время реакции на наш ответ будет составлять в лучшем случае 1мС (1000 мкС!) и колебаться в десятки раз от запроса к запросу.
Ну и что мы сэкономили? 0.1...1% в самом оптимистичном случае? Погрешность измерений в таких процессах больше будет. Хотя если с сравнивать обычную ОС с FPGA, то казалось бы да — до ста раз быстрее!
Если на нашем конце обрабатывать всё в обычной ОС, то время реакции будет 30..100 мкС (от момента, когда последний электрический импульс пакета попал в сетевую карту, то момента, когда сетевая карта начала передавать ответ).
Если извращаться с реальным временем, обработчиками прерываний и т.п., то время реакции будет 3-10 мкС. На FPGA можно добиться реального времени реакции ещё на порядок меньше — что-то порядка 1 мкС.
А теперь внимание.
После передачи наш ответный пакет пройдёт через несколько маршрутизаторов (биржа обслуживает тысячи клиентов).
Попадёт в сетевую карту сервера биржи и от туда в очередь пакетов буфера приёма (у них много клиентов и все что-то шлют). Наш пакет может быть в очереди первым, а может быть тысячным.
Дальше какей-то время нужно планировщику пакетов сервера, чтобы обработать другие задачи и запустить драйвер сетевой карты и обработчик стека TCP/IP.
Потом будут обработаны все пакеты из очереди.
Клиентов, как я говорил у биржи тысячи. Поток данных — огромный. Нужно ещё обеспечить надёжность. Теряется время на межпоточную синхронизацию. Нужно обеспечить надёжность — должен быть не один сервер, а несколько. Одновременно идут миллионы сделок — это всё тоже нужно обрабатывать. Нужно всё кидать в какую-то базу данных.
Чувствуете, как нарастает сложность и время обработки?
В общем, есть мнение, что ИХ время реакции на наш ответ будет составлять в лучшем случае 1мС (1000 мкС!) и колебаться в десятки раз от запроса к запросу.
Ну и что мы сэкономили? 0.1...1% в самом оптимистичном случае? Погрешность измерений в таких процессах больше будет. Хотя если с сравнивать обычную ОС с FPGA, то казалось бы да — до ста раз быстрее!
можно ссылку на оригинальную статью?
Спасибо заранее
Спасибо заранее
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Высокочастотный трейдинг (HFT) с использованием FPGA