Сегодня заглянул на форум Московской Биржи в раздел «Срочный Рынок» и увидел забавную тему с названием «Продается возможность стать самым быстрым на FORTS». Автор с ником HalfBe начинает ее сообщением:
-------------------------------------------------
На торги выставляются три лота:
1. Два сервера на М1 в зоне коллокации биржи, подключены к сети биржи через канал 10GB, выполнены настройки и оптимизации для достижения минимальной латентности. Серверы HP DL360 G6, конфиг достаточен для того, чтобы стать самым быстрым.
2. Исходные тексты оптимизированных модулей для подключения напрямую к Plaza2 в обход раутеров и других прослоек, пожирающих драгоценные десятки микросекунд.
3. Беседа продолжительностью два часа на тему «Как стать самым быстрым на ФОРТС» с подробными инструкциями (без пункта 2. стать самым быстрым не получится, поэтому нужно быть готовым либо его купить, либо самостоятельно реализовать)
Предложения с ценами за каждый лот в личку.
--------------------------------------------------
Являясь разработчиком робота HalfBe, хочу прояснить несколько моментов
1. Я не знаком с автором под ником HalfBe
2. Наша команда никогда не использовала нелегальные подключения «напрямую к Plaza2 в обход раутеров и других прослоек»
3. B cамое главное. Робот HalfBe хотя и относился к категории HFT, реально быстрым не был.
Во-первых, торговая логика была написана на VBA
Во-вторых, сигналы на сделки формировались на основании данных с западных бирж, которые получались через CQG — не самого быстрого из поставщиков данных
В-третьих, связь с FORTS осуществлялась через SQL-серверы. Именно во время ЛЧИ биржа стала переходить на Plaza и примерно с середины конкурса начала вводить исскуственные задержки для ордеров, подававшихся через SQL с тем, чтобы стимулировать скорейший отказ от старой технологии. К концу конкурса задержки в постановке ордеров в моменты активного рынка достигали 5 секунд. Тем не менее робот продолжал выигрывать (хотя и не должен был).
Поэтому прошу учитывать, что скорость — не панацея. Будучи очень важным фактором она, тем не менее, не является залогом успешной работы робота, даже высокочастотного.
PS. Прошу прощения у автора с ником HalfBe, если подпортил ему коммерцию, но истина в данном случае важнее.
И почему SQL — если у чела аналог роутера? Как-то странно все. Выгоднее, кажется, купить одни сорцы, выдрать оттуда спецификацию API к плазе и на FPGA все перенести. А на серверах тслаб поставить:)
Мой потертый комент лишь иллюстрировал мысль что профи зачастую используют более простой инструментарий чем предполагает широкая публика.
ну и переход с sql был несколько лет назад так что чел просто продает старую тачку :)
жалко правда что продает а не выкладывает в общий доступ — видимо совсем туго стало
во-вторых скорости их в разы больше чем сеть, так как сетка гигабиты, а память гигабайты. Но это не достижимые значения, но узкое место в данном случае сеть.
у вас будет транзакционная нагрузка, малыми блоками, поэтому там гораздо ниже будет скорость.
да, в кэше профессора держать программу, наверное одно из правильных направлений если речь идет о высокочастотном трейдинге.
Я тут долго и упорно выяснял с парнями из Rithmic как я могу сократить свои временные издержки (малеха их не сразу понял, а они меня не просвятили до тех пор пока я не стал задавать вопросы). Так вот у меня волосы добым встали от 3.5 микросекунд. Теперь через отложенный ордер буду пытаться выйти на их заявленные 200-250 микросекунд. Это СМЕ пацаны. Это HFT. А через прямое соединение и 50-75 микросекунд от приема информации до трейда думаю вполне возможно…
мне не хватит таких задержек — вероятно СМЕ более конкурентный рынок