Комментарии 24
Я думаю, что ваши статьи бы стоило начинать с ликбезов о влиянии лишней мс на результативность торговли, потом двигаться от java к C++, от низкочастотных cpu к вымокочастотным, к отключению ядер и гипертрединга, управлению профилем энергоэффективности. А так склпдывается впечатление, что вы умеете что-то экономить, а для чего не знаете. И мы нпюе узнаем. И как же в Nasdaq воткнуться проводом? Может с этого стоило начать? Или с того, что Nasdaq чаржит клиентов по 200-500$ в час за обслуживание продуктов их инженерами. Я с трудом могу представить сколько будет стоить воткнуться туда проводом, а Вы о каких-то пикосекундах. Здесь 99.9% Arista cut-through в глаза не видели, а вы про превращение свича в хаб...
Иван, безусловно, выбор языка, оптимизации кода, тюнинг ядра ОС, выбор CPU и оверклокинг - все это также неотъемлемые части этой битвы за снижение задержки. И о них можно много писать. О том как встать в колокации бирж и об их инфраструктуре и прайсинге можно тоже не один пост написать. Но конкретно в этой заметке я выбрал такой формат, где я затронул зону своего интереса в этой тематике, надеюсь, для кого-то он тоже будет интересен.
Просто все это не близко на фоне непонимания сути проблемы.
Суть проблемы вакации изложена в первом абзаце, но я постараюсь впредь начинать подводку еще более издалека, и больше затрагивать смежные темы. Я понимаю что интересно было бы проанализировать влияние задержки на хитрейт, но такой анализ лежит за рамками данного формата.
Ну автор Вы. Я просто хотел Вам помочь сделать ваши статьи интереснее. Так-то не возбраняется. Интересно, кто-нибудь на Xilinx-овых FPGA-бордах с интерфейсам сетевыми торгует, чтобы уж по хардкору, точно фиксированный рилтайм?
А что с OpenVswitch и прочим оффлоадингом на базе карт Silicom и иных очень ускоренных NIC с развитой логикой преобработки и фильтрации потоков?
BGP можно и с хоста вещать, там на latency пофиг. Кстати, зачем вы пишете про BGP в рамках данной тематики - это вроде как непрофильный топик. Никак особо не влияет, кроме технического подключения для маршрутизации...
При использовании Xilinx FPGA плат можно тоже отдать в систему весь этот сервисный трафик (BGP, PIM). Ну а торговую логику реализовывать на FPGA. Статья касается именно сервисного трафика, так как обычно эти протоколы BGP/PIM обслуживаются на сетевом оборудовании, а тут вынуждено на хосте. Кстати, есть также смежное решение типа Xilinx Alveo, где на плате есть еще ARM ядра, но увы, они не так быстры как современные десктопные/серверные процессоры.
Я могу ошибаться, но для большинства здесь находящихся - 1мс, минимальный ощутимый (tangible) квант времени. Было бы интересно понять весь "стек" экономии времени, где можно сколько сэкономить, переходя от технологии X к технологии Y.
Согласен, интересная тематика. Про разницу в сотни мс я тут писал, в своей статье в песочнице: https://habr.com/ru/post/715452/
потом двигаться от java к C++, от низкочастотных cpu к вымокочастотным, к отключению ядер и гипертрединга, управлению профилем энергоэффективности
Это всё базовые вещи. Но внезапно они оказываются тоже бесполезны, когда конкурент имеет доступ к более «правильному» гейту, или вообще имеет инсайд (в техническом плане). Увы, такое является не редкостью и поныне...
P.S.: > Cisco Nexus 3550 Fusion (в прошлом Exablaze ExaLINK Fusion ... Arista ... в прошлом Metamako
Как быстро меняется этот мир, а соларфларь ушла к зайлинксам, а те к амуде... мелланокс теперь нвидия. Только успевают копирайты в исходниках править...
Было бы интересно прочитать обзорную статью с описанием требований к задержке для таких систем (типа для таких задач задержка в среднем должна быть N наносекунд), какие элементы какую задержку вносят, технологии по ее оптимизации.
для таких задач задержка в среднем должна быть N наносекунд
В трейдинге только один критерий: задержка должна хотя-бы на пол-шишечки быть ниже, чем у конкурента. И не важно, боретесь вы 1 микро против 900 нано, или 100 милли против 99999 мкс
Это как анекдот про то, с какой скоростью надо убегать от медведя.
Понятно, что чем меньше тем лучше. Но интересно в среднем в каком диапазоне она у участников. И какими улучшениями она достигается (порт на оптическом кроссе - столько то нс, 1 км ВОЛС на улице - столько-то нс и тд).
(порт на оптическом кроссе - столько то нс, 1 км ВОЛС на улице - столько-то нс и тд).
эти данные есть в школьном учебнике физики.
в каком диапазоне она у участников
а этими никто добровольно делиться не будет, более того, много кто считает коммерческой тайной (хотя по факту это секрет полишинеля, но для каждой биржи свой, могут отличаться на порядки)
честно сказать вообще не понял как и зачем тут бжп.
тип если так важна минимизация задержки то проще захардкодить роуты чем поднимать для этого демона.
да и вообще, если смычка между биржей прорабатывается в терминах долей мс, то имеет наверное смысл вообще отказаться от л3 ?
Без объявления обратного роута к вашему «клиенту» с ним не будет коммуницировать биржа, на биржевом коммутаторе только /30 сетка для пиринга с клиентским коммутатором. Так что это требование биржи.
Для ядра что статик, что bgp route одинаковы с точки зрения рутинговых затрат.
отказ от л3 полезен только для субмикро, для всего остального и так сойдёт
И что, никто так и не упомянул "Операцию "Колибри"?! ;)
Настройка прямого подключения к инфраструктуре биржи для получения преимущества за счет минимизации сетевой задержки