FiNick
|
Date: 9/26/2011
frontman Смотрите опытным путем установил что событие ITrader.NewOrders вне стратегии срабатывает.
Но как только я переношу подписку на это событие в стратегию ничего не работает.
Это наводит на мысль что это связанно с классом Strategy как то... А как вы регитрируете заявку, strategy.RegisterOrder или plaza.RegisterOrder? Если вторым образом, то события стратегии типа strategy.NewOrders, OrderChanged и т.п. не будут срабатывать. Стратегия не считает такие заявки своими, потому никак не сообщает о них.
|
|
|
|
Thanks:
|
|
|
|
|
|
frontman
|
Date: 9/26/2011
strategy.RegisterOrder
Но проблема в том что я обрабатываю событие ITrader.NewOrders, а оно к стратегии не относится ни как... И по идее должно перехватывать все заявки... Но...
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/26/2011
Выяснил.
Задержка, как и писал неоднократно выше, связана с PollTimeOut в PlazaConnectionPool.
У нас заявки посылаются асинхронно, в том же потоке, что делает ProcessMessage. Могут возникать ситуации когда они блокируют.
Поставил 100мс, как советуют на форуме РТС.
Далее. Сейчас у нас создаётся 1 подключение для данных и для отправки заявок. Что не оптимально.
Предлагаю добавить возможность создавать N (>=1) транзакционных подключений для отправки заявок. В любом случае транзакционное подключение необходимо отделять от потока данных. В этом случае всякая проблема с задержкой заявок уйдёт.
Замечания \ пожелания \ предложения?
P.S. Свой минификс со 100мс залил на codeplex, соберите по исходникам, потестируйте.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 9/26/2011
Alexander Далее. Сейчас у нас создаётся 1 подключение для данных и для отправки заявок. Что не оптимально.
Должно быть раздельно сделано, одно для данных, одно для транзакций. Посмотри, где вызывается класс PlazaConnectionPool.
|
|
|
|
Thanks:
|
|
|
|
|
|
frontman
|
Date: 9/27/2011
Я думаю даже 100мс скоро много будет)
У меня вопрос : а не может ли тот факт что транзакции и получение данных идет в одном потоке мешать выполнению этих самых транзакций.
Т.е я говорю не о задержки как писал Александр а о полной блокировки. Например при получении данных о стакане? Т.к. стакан обновляется постоянно, т.е поток входной инфы практически бесконечен?
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
frontman Я думаю даже 100мс скоро много будет) С чего мало? Эти 100мс передаются в ProcessMessage. Для чего они там нужны - см. документацию плазы. Хотите - измените на поменьше, это делайте через свойство StreamTimeOut. Quote:
У меня вопрос : а не может ли тот факт что транзакции и получение данных идет в одном потоке мешать выполнению этих самых транзакций.
Т.е я говорю не о задержки как писал Александр а о полной блокировки. Например при получении данных о стакане? Т.к. стакан обновляется постоянно, т.е поток входной инфы практически бесконечен?
Так и происходит. Только у нас 2 коннекшена - 1 для данных, 1 - для транзакций. Я по коду проверил, всё должно быть в порядке. Вы протестировали с изменениями? Как результаты?
|
|
|
|
Thanks:
|
|
|
|
|
|
frontman
|
Date: 9/27/2011
Ну могу сказать точно что заявки стали быстрее выставляться... Но моя проблема с получением ответа от биржи о выставлении заявки сохранилась(
|
|
|
|
Thanks:
|
|
|
|
|
|
frontman
|
Date: 9/27/2011
Александр а вы пробовали одновременно создавать вот такие правила? Code
this.When(Security.MarketDepthChanged())
.Do<MarketDepth>(MarketDepthChanged);
this.When(this.StrategyNewOrder())
.Do<Order>(order => this.AddOrderInfoLog(order, "Выставленна"));
|
|
|
|
Thanks:
|
|
|
|
|
|
FiNick
|
Date: 10/6/2011
Повторно подниму эту тему.
На сколько я понимаю рефакторинг позволил создавать множество коннекшнов до гейта и соответственно обрабатывать потоки репликации в нескольких тредах. Похоже это не роскошь, а необходимость.
Я отсылал в РТС логи, они сделали такие замечания:
По приложенному логу видно, что накапливается очередь сообщений в первые секунды работы.
2011-10-06 16:45:47.234;p2mq-cli;;New message added to recvList. Size: 38
Это приводит к задержкам в получении данных, поэтому предлагается побороться с очередями. Для этого предлагается разбить получение реплики на несколько соединений, работающих в отдельных thread'ах, каждое со своим циклом выборки.
P.S. Начал прикидывать как это можно сделать, пока не получается, все ломается
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 10/7/2011
FiNick Повторно подниму эту тему.
На сколько я понимаю рефакторинг позволил создавать множество коннекшнов до гейта и соответственно обрабатывать потоки репликации в нескольких тредах. Похоже это не роскошь, а необходимость.
Я отсылал в РТС логи, они сделали такие замечания:
По приложенному логу видно, что накапливается очередь сообщений в первые секунды работы.
2011-10-06 16:45:47.234;p2mq-cli;;New message added to recvList. Size: 38
Это приводит к задержкам в получении данных, поэтому предлагается побороться с очередями. Для этого предлагается разбить получение реплики на несколько соединений, работающих в отдельных thread'ах, каждое со своим циклом выборки.
P.S. Начал прикидывать как это можно сделать, пока не получается, все ломается несколько соединений - connection pool а рефакторинг позволил создавать несколько PlazaTrader
|
|
|
|
Thanks:
|
|
|
|
|