Я хотел бы создать приложение, способное воспроизводить исторический тик с помощью тиковых многоуровневых книжных изменений. Мой вопрос: как можно это сделать?
Непосредственная проблема, с которой я сталкиваюсь, состоит в том, как имитировать фактический пакет данных? Пакет данных здесь определяется как большой объем событий, происходящих в течение определенного промежутка времени (скажем, микросекунд). Например, если бы я просто просматривал событие данных по событиям и публиковал их для своих потребителей, это не учитывало бы фактическую разницу во времени между последовательными событиями, происходящими в реальной жизни. Поскольку рыночные данные поступают асинхронно, мне нужно уметь это моделировать.
Любые предложения или ресурсы высоко ценится.
Спасибо,
С учетом заявленного определения требований к такому эмулятору высокой точности для реалистичного потока событий, необходимых для проверок HFT, ваш выбор дизайна не безграничен.
Учитывая, что только один инструмент (GBDUSD) может генерировать многие тысячи (да, многие тысячи) изменений L3-DoM в одном и том же [usec] (да, в пределах одной и той же микросекундной доли времени), ваш проект должен выбирать между двумя основными пути:
идти распределенным путем (используя набор удаленных ресурсов), чтобы внедрить этот огромный поток событий в своего рода контролируемом потоке времени, независимо от вашей фактической рабочей нагрузки (локального хоста) / свободных вычислительных мощностей
перейти на путь FPGA (используя внутренне подключенное оборудование PCIe), который может помочь внедрить упомянутый поток событий, опять же, независимо от пользовательских операций
В любом случае, это далеко не иллюзия того, что может принести в жизнь хакатон на выходных или спонсируемые вилки.
Доступность & статические масштабы всех исторических данных L3-DoM с метками времени + записи о потоке торговых событий не проблема. Высокоточный поток времени (организованный на основе основанного на введении ввода генерируемых рынком сообщений в высокодинамичное моделирование с двунаправленным потоком транзакций), находящийся на единственной стороне потребителя, близкой к производительности оборудования конверт, определенно является.
Как сказал Сеймур КРЕЙ:
«Любой может построить быстрый процессор. Хитрость в том, чтобы построить быструю систему.«
Построение системы, которая работает медленнее, чем в режиме реального времени, кажется менее требовательным, но такой подход никогда не сможет снова завоевать рынок (не говоря о запуске какой-либо стратегии оптимизации в некотором пространстве гиперпараметров, где дополнительное неблагоприятное масштабирование PSPACE | PTIME
, но чаще EXPSPACE & EXPTIME
переместить любую такую попытку в тупик ограничений вычислимости, чтобы ожидать каких-либо результатов в разумных пределах реального времени, доступных для запуска такой моделируемой / оптимизируемой системы.
Других решений пока нет …