NinjaTrader Конвертирование NT8 MarketReplay файлов в текстовый формат

[ryarom148]

@futuresishere,​

еще один вопрос: если я скачиваю два файла replay, к примеру 18 октября и 19 октября,

addon создает два файла: 18 и 19 октября, но 19 октября пустой, а данные из 19 октября сохраняются в 18 числом, а replay из Ninja 18-го числа полностью игнорируется. Это предусмотренная Вами логика?​

 

[rare312]

futuresishere спасибо за addon​

Добрый день! запустил конвертацию, все работает.
Теперь вопрос. Возможно кто-то уже сталкивался с этим:
1) если взять комбинацию файлов: .Last.txt (экспорт из Ninja) и Replay.csv ( конвертация market_replay).
2) по логике они должны быть синхронизированы по времени: время из Last ( трейд) должен вызвать изменения в L2 , и bid и ask должны как-то соответствовать как в Last, так и в Replay. у меня DateTime в Last практически никогда не совпадает с DateTime в L2, то есть я не могу определить влияние трейд на order book.
Кто-то сталкивался с этой проблемой?

У вас время last совпадает в обоих файла? То есть время фактического трейда.. Совпадает, значит хорошо.
L2 это время изменений в стакане. И это время не должно совпадать со временем трейдов. стакан может обновиться перед трейдом, может после. А может и синхронно.
Как определять влияние трейда на стакан - нужно знать на каких ценах был стакан во время трейда, и что случилось после трейда.

 

[ryarom148]

В том то и дело, что не совпадает ( время в last не присутствует в L2)
Стакан по сути должен обновляться
1) Новый ордер,
2) отмена ордера ( изменение)
3) и трейд ( агрессивный ордер).

Tickreplay dump
Есть два вида L2 и L1 ( здесь L1 и L2 синхронизированы по timestamp). Но
L1 почему- то только два вида ( ask ( 0) и bid ( 1), но нет last ( 3), поэтому я хотел взять транзакции ( сделки) из Last , чтобы определить Время изменения стакана из-за агрессивной сделки.
Исходя из опыта работы с другими форматами данных, как order logs , этих проблем не возникало.
Но здесь ( возможно я что-то не понимаю), стакан живет своей жизнью, last живет своей , и bid и ask в last не совпадает с L2, даже учитывая тот факт что bid и ask в last, даны до сделки ( чтобы определить buy это или sell).
Не зависимо от того, что идёт первым или вторым , timestamp везде должен совпадать.
Вот такая грустная история !!
Я очень надеюсь , что это у меня проблемы с пониманием, а не проблем c market data

 

[rare312]

пока автора нет. Проверьте программу от NT8- создателя ветки. Все аналогично аддону или по другому..

 

[futuresishere]

@ryarom148, этот AddOn опирается на незадокументированную возможность NT8, которую они уже несколько лет обещают задокументировать, но не делают этого (скорее всего им необходима закрытая экосистема, а такого роде экспорты позволяют лить данные из проприетарного формата во что угодно).

В силу особенностей API часовой пояс при экспорте локальный, а не UTC, к сожалению (это даже не часовой пояс торговой площадки инструмента). Поэтому все смещения, склейки через день и анализ надо потом делать самому.

Сам аддон просто выливает nrd данные никак не преобразуя, то есть что дали на входе то и имеем на выходе в видк CSV.
Соотвественно, если L1 и L2 не совпадают в каком-то месте, то эта же проблема присутствует и в самом nrd файле.
Ни AddOn, ни UI утилита не знают с каким данными они работают, все что они делают это говорят NT8: возьми этот nrd и вылей в этот csv и всё.

 

[futuresishere]

В догонку: из тех данных с которыми я сталкивался L1 и L2 вообще редко имеют что-то общее и мало как пересекаются с границами торговых сессий, PreMarket, PostMarket и даже выходными.

Я получал выставленные/снятые/обновленные ордера когда угодно, включая праздники и выходные. Так что лучшей стратегией будет фильтровать записи по торговым перидам инструмента с учетом его расписания на праздники выходные, сокращенные дни и самому пробежаться и подсчитать OHLCV аггреграты секундок, минуток, и т. д. на основе реальных сделок.

Тогда полученные графики будут точно повторять графики других сетевых ресурсов по данныму инструменту за данное время.
Но возможно у вас более надержный источник nrd с уже обработанными почищенными и согласованными между собой L1/L2 данными.
В конннце концов триплет [Timestamp + Price + Volume] каждой реальной сделки (+ иногда состояние стакана на эту временную метку) есть единственный первоисточник всего остального.

 

[my-trade]

В силу особенностей API часовой пояс при экспорте локальный

Вы не здесь ни в описании на GitHub не указываете, какой конкретно часовой пояс то... если не пояс торговой площадки. Есть информация по этому поводу? Спасибо

 

[NT8]

какой конкретно часовой пояс то

Так написано же - локальный

 

[my-trade]

Так написано же - локальный

Ааа... мой локальный)). Понял. Не знаю почему, мне показалось что локальный для серверов NinjaTrader... вот эта фраза: (local NinjaTrader timezone is used), как будто это таймзона нинзятрейдера, а не моя). У меня что программирование, что английский - всё на одном уровне :)

 

[my-trade]

Так написано же - локальный

Так... разобрался. В аддоне futuresishere используется локал, который уканан в настройках NT8 (Сервисы -> Дополнительные настройки), а не локал виндовс. А в вашей программе используется локал из виндовс.

 

[my-trade]

Утилитка для конвертации

Я тут баг словил в вашей утилитке, скришнот сравнения с аддоном от @futuresishere тоже (в нём всё корректно сработало).
На выделенной черным цветом строчке что-то пошло не так.. и все последующие строчки тоже из-за этого "поехали"...
Было бы хорошо, если б вы глянули этот момент и нашли решение, спасибо

Ссылка на реплей ТУТ. (ES 09-19 20190904.nrd)

UPD:
Вот засада... баг повторно воспроизвести не удалось!!! Сконвертировал ещё раз - всё прошло корректно!

 

[NT8]

Будет время, гляну.