EventChartCustom => indicator is too slow - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как стата собиралась?
Шпион передает GetTickCount64, советник в ОнЧартИвент обрабатывает все поступающие тики и делит их на 2 пачки: старее 16 мс (погрешность GetTickCount) и новее. Для каждой группы считает среднюю задержку.
Отдельно засекается суммарное время выполнение всех торговых Order*-функций (Total trade requests time).
Шпионы в сочетании с отсевом устаревших тиков работают исправно.
Шпионы в сочетании с отсевом устаревших тиков работают исправно.
Буду тестировать. Спасибо
@Slava, а если поступить так:
разделяем логику мультивалютного советника на отдельные торговые советники и ещё советник-менеджер, торговые советники по каждому символу пишут прайсы в глобалы терминала, а менеджер эти данные анализирует и дает команды туда же в глобалы торговым советникам.
как считаете, за счет того. что всё это хозяйство советников работает каждый в своем потоке, можно ли достичь ощутимого преимущества над использованием в едином мультивалютнике OnTimer () или OnChartEvent ()?
понятно, что реализация такой схемы значительно сложнее и в тестере работать не будет, но для ускорения можно и заморочится, а для тестирования использовать простой вариант с агентами и OnChartEvent ().
если глобалы терминала достаточно шустрые, то овчинка, вроде как, должна стоить выделки.
Мы планируем набор ThreadXXX функций по запуску и управлению отдельными копиями программ. Плюс более мощное окно Experts/Task Manager.
Можно будет в качестве ресурсов подключать EX5 файлы как скрипты с точками входа OnStart, которым будет передаваться управление.
Также добавим прямые функции обмена данными между программами.
Мы планируем набор ThreadXXX функций по запуску и управлению отдельными копиями программ. Плюс более мощное окно Experts/Task Manager.
Можно будет в качестве ресурсов подключать EX5 файлы как скрипты с точками входа OnStart, которым будет передаваться управление.
Также добавим прямые функции обмена данными между программами.
Добрый день, Ренат!
Отличные новости. Можете прокомментировать моё сообщение Славе, пожалуйста? Планируемые MQ нововведения решат на 100% мою задачу, но кушать, как водиться, нужно уже сейчас и требуется самое быстрое решение.
По моему, так можно избавится даже от необходимости использования асинхронного OrderSend (), так как в МТ5 нет проблем с "контекст бузи" как в МТ4.
Добрый день, Ренат!
Отличные новости. Можете прокомментировать моё сообщение Славе, пожалуйста? Планируемые MQ нововведения решат на 100% мою задачу, но кушать, как водиться, нужно уже сейчас и требуется самое быстрое решение.
По моему, так можно избавится даже от необходимости использования асинхронного OrderSend (), так как в МТ5 нет проблем с "контекст бузи" как в МТ4.
Пробуйте, это ведь без нас можно сделать.
Или вы оставили за кадром невысказанные мысли про изменения с нашей стороны?
Ладно, ответа от специалистов я не дождался...
Самая быстрая схема такая:
Скрипт в бесконечном цикле получает по символам SymbolInfoTick () со Sleep (1) (можно и без слипа вовсе, нынче процы более чем с одним ядром), делает анализ и в случае надобности отправляет чарт эвенты соответствующим торговым роботам.
... отсутствует возможность тестирования в тестере. на этот случай нужно делать специальный вариант ТС на основе агентов.
Кроме того, вяснил, что отправка пушей и мэйлов не "бесплатная", тем кто всё же хочет пользоваться уведомлениями на смарт необходимо озаботится о менеджере сообщений на смарт в виде отдельного эксперта.
Вопрос: как пропустить тики, которые советник не успел обработать (реагировать только на последний тик из очереди)?
обработка очереди — дело OnChartEvent запущенных на чарте программ (и тормозить должны они, если событий много).
Есть идея — передавать из индикатора текущий GetTickCount, а в советнике пропускать "тики", которые родились больше Х мс назад. Но есть риск пропустить нужный (один из последних) тик по инструменту.
Хотелось бы больше контроля над очередью событий. Или, хотя бы, полного понимания, как она работает.
@Slava, @Renat Fatkhullin, помогите, пожалуйста.
Рецепт простой: обрабатывать не очередь, а стэк тиков. Как его сформировать - Вам виднее.
Например, обрабатывать данные не слева направо, а справа налево, пока не наступит новое событие, либо не дойдём до уже обработанного тика. Что раньше. Будут пропущенные тики, но - неактуальные, скорее всего. Зависаний быть не должно.
Извините, что встрял.