Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Но я смотрю в лог , а по логу один и то же тик с разницей в 4 секунды приехал.
p.s.
Очень не люблю фразу - мысль "не может быть" , давно привык к тому что может быть все что угодно.
К слову, возможно это далеко от темы, но когда то на утверждение, что земля круглая тоже говорили примерно так же - "этого не может быть".
Вообще всегда сомневаюсь , пока не проверю потом перепроверю, и желательно кто то еще перепроверит несколько раз.
У Вас точно код не лажает - который формирует лог, обрабатывает данные ? а то выходит 4 секунды разница
Тики уже в терминале, т.е они уже переданы по сети.
Код в открытом доступе подставьте в него
И сами посмотрите
Тики уже в терминале, т.е они уже переданы по сети.
Код в открытом доступе подставьте в него
И сами посмотрите
Спасибо, попробую, давно слежу за темой, мне интересно скорее как исследователю.
это этот код лаганул на 4 секунды ?
Похоже не этот
не вижу в коде OnTick
Видимо речь шла об этом коде
Добавил в код свое время.
Запоминаю время, когда сработал OnTick() (t_time = GetMicrosecondCount();)
Затем беру время, при выполнении каждой функции
Результат
Т.е время выполнения каждой функции менее 50 микросекунд!
Откуда может взяться 4 секунды?
Думается, что работали два советника в одном терминале, а терминал просто не успевает
"сливать" в один лог всю инфу, вот и ставит локальное время как считает нужным.
В торговых операциях, лично я, использую асинхронные ордера.
Дело в том (если серьезно торговать на Бирже), то нужны все изменения стакана,
и чем быстрее это событие придет - тем лучше.
Я, для себя, не вижу альтернативы ОнБук
Можно в принципе разгрузить непосредственный вызов торговых операций из ОнБук. В ОнБук всего лишь формировать флаг на необходимость исполнить операцию, сам флаг обрабатывать уже в другом месте. Т.е. саму операцию начинать в другой процедуре по сформированному флагу, который создаст событие, но после выхода из процедуры ОнБук, и тогда сам код ОнБук останется свободным от тяжелых операций. Впрочем если ордера открываются асинхронно , и нет безумно большой обработки условий , то вряд ли это вызовет существенные задержки.
Добавил в код свое время.
Запоминаю время, когда сработал OnTick() (t_time = GetMicrosecondCount();)
Затем беру время, при выполнении каждой функции
Результат
Т.е время выполнения каждой функции менее 50 микросекунд!
Откуда может взяться 4 секунды?
Думается, что работали два советника в одном терминале, а терминал просто не успевает
"сливать" в один лог всю инфу, вот и ставит локальное время как считает нужным.
Пожалуй верно , мало реальна такая дикая задержка.
1 - FLUSH отработал когда MQ это решил сам!
2 - Техническаа задержка записи на диск связанная с интенсивной работой с жестким диском
Возможно какая то очередь на запись уже на вашей локальной машине - что вполне реально, имел опыт когда на диск лилось несколько терабайт бекапа
могу лишь предположить следующее:
например если в этот момент параллельно ставить макйрософт офис - обновлять виндовс и записывать какой нибудь фильм из интернета , интенсивно работать с MS SQL который стоит на локале,
делать пару бекапов , иметь десятка 4 торентов ну и еще два три десятка программ интенсивно пишуших на диск.
т е я хочу сказать что если была интенсивная работа с диском - вполне возможно и возникла задержка записи лога на диск.
Пожалуй верно , мало реальна такая дикая задержка.
1 - FLUSH отработал когда MQ это решил сам!
2 - Техническаа задержка записи на диск связанная с интенсивной работой с жестким диском
Возможно какая то очередь на запись уже на вашей локальной машине - что вполне реально, имел опыт когда на диск лилось несколько терабайт бекапа
могу лишь предположить следующее:
например если в этот момент параллельно ставить макйрософт офис - обновлять виндовс и записывать какой нибудь фильм из интернета , интенсивно работать с MS SQL который стоит на локале,
делать пару бекапов , иметь десятка 4 торентов ну и еще два три десятка программ интенсивно пишуших на диск.
т е я хочу сказать что если была интенсивная работа с диском - вполне возможно была задержка записи лога на диск.
Добавил в код свое время.
Запоминаю время, когда сработал OnTick() (t_time = GetMicrosecondCount();)
Затем беру время, при выполнении каждой функции
Результат
Т.е время выполнения каждой функции менее 50 микросекунд!
Откуда может взяться 4 секунды?
Думается, что работали два советника в одном терминале, а терминал просто не успевает
"сливать" в один лог всю инфу, вот и ставит локальное время как считает нужным.
кстати - что бы не грешить на время записи в лог - можно добавить локальное время в массив - который вы формируете в коде - ниже
Тогда в логе будет четкая разница между временем когда терминал соизволил сбросить лог на диск и временем локальным когда приехал тик или событие ОнБук.
И это будет более правильно с точки зрения исследования.
Вряд ли с диском связано, время МТ ставит уже при записи лога в кэш свой. Вот что задумался терминал вообще на 4 сек может связано быть с общей загрузкой системы, скорее оперативки и проца.
ВЫ В ЭТОМ УВЕРЕНЫ ?
4 секунды ???? , да нееет! Реально полагаете процессор завис на 4 секунды или память выделялась освобождалась 4 секунды ? Вы шутите.
Более вероятно это очередь записи на диск.
Диск устройство более медленное чем память и процессор.
А потом flush() , есть такая команда в языке Си, наверняка знаете, она выполняется когда ей удобно и комфортно и может выполнятся с некоторой задержкой чаще связанной с загрузкой диска.
Именно ее вызывают когда нужно сбросить буфера на диск.