Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Оказывается, частое явление. Торговые функции не вызывал.
SymbolInfoTick нехило иногда тормозит. HFT может оказаться очень опысным с такими неожиданным лагами.
Просьба к Разработчикам найти причины. Пока же становится очевидным, что в боевых советниках свой профайлер - обязательная вещь.
Что покажет тест на "пустом" терминале?
Должно быть примерно так:
Если детально не рассказываете что вы делаете, как именно вы создаете нагрузку на терминал, то нам будет сложно найти причины.
Что покажет тест на "пустом" терминале?
Должно быть примерно так:
Если детально не рассказываете что вы делаете, как именно вы создаете нагрузку на терминал, то нам будет сложно найти причины.
100K итераций - не показатель. Т.к. функция тормозит не всегда, а иногда.
Фактически мне надо отключать куски боевого советника до тех пор, пока не прекратятся тормоза. Тогда смогу предоставить код. Надо подождать.
Фактически мне надо отключать куски боевого советника до тех пор, пока не прекратятся тормоза. Тогда смогу предоставить код. Надо подождать.
Для быстрого получения результата запустить этот советник на нескольких символах.
За пять минут получил.
Похоже, достаточно оставить только это (без CopyTicks) в советнике.
100K итераций - не показатель. Т.к. функция тормозит не всегда, а иногда.
Предлагаю изменить концепцию определения быстроты функции.
Функция быстрая, если нет пиков длительности ее выполнения.
Как выше было показано, даже простые функции такие пики имеют. Иногда очень большие. Понятие не имею, с чем это связано. Но очевидно, что нужно все критические для торговли функции проверить на наличие пиков методом, как было предложено. Т.е. запускаем и мониторим пики больше миллисекунды в течение пары часов.
Нужно добиться, чтобы пиков не было хотя бы на пустом Терминале. Быстрые 100К итераций, как оказалось, - ни о чем.
Предлагаю изменить концепцию определения быстроты функции.
Функция быстрая, если нет пиков длительности ее выполнения.
Как выше было показано, даже простые функции такие пики имеют. Иногда очень большие. Понятие не имею, с чем это связано. Но очевидно, что нужно все критические для торговли функции проверить на наличие пиков методом, как было предложено. Т.е. запускаем и мониторим пики больше миллисекунды в течение пары часов.
Нужно добиться, чтобы пиков не было хотя бы на пустом Терминале. Быстрые 100К итераций, как оказалось, - ни о чем.
Иногда бывает что таймер показывает совокупный объем времени если запущена другая задача. К примеру такое бывает при работе с канвасом - при отображении функция ставит задачу на отображения не создавая изображения и возвращаеться. Далее выполняется любая другая функция которая идет обязательно последовательно - к примеру тот же комент, однако на языке проца начинает проиходить процес отображения канваса и только после отображение комента. И при измерении тайминга можно увидеть что комент очень долго выводиться. а вот функция отображения канваса сработала за 0 мс.
запускаем и мониторим пики больше миллисекунды в течение пары часов.
Нужно добиться, чтобы пиков не было хотя бы на пустом Терминале. Быстрые 100К итераций, как оказалось, - ни о чем.
Набросал такой советник-мониторинг.
Результат за пять минут мониторинга.
ЗЫ При таком значении входного параметра алертов гораздо меньше.
Но и результат показательнее.
Наконец, у меня модификация пачки ордеров иногда занимает по 3-10 секунд на каждый ордер. После чего снова долгое время по 0.1 секунды.
Поднимали логи сервера - там мгновенно.
На боевом советнике очень неприятно.
Какие-то фантастические значения.
Наконец, у меня модификация пачки ордеров иногда занимает по 3-10 секунд на каждый ордер. После чего снова долгое время по 0.1 секунды.
Поднимали логи сервера - там мгновенно.
Ситуация повторилась на другом торговом сервере.
Терминал модифицировал тейк открытой позиции 2.5 секунды. На сервере - 2 миллисекунды.
Скорее всего, и отсюда растут ноги проблем с ФОРТС-исполнением.
Ретрансмиты.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Бета-версия платформы MetaTrader 5 build 1700: Проекты в MetaEditor и синтетические инструменты
Renat Fatkhullin, 2017.12.14 12:47
Это показатель качества связи. Процент повторно отправляемых сетевых пакетов в TCP/IP протоколе.
Считается глобально на уровне сетевого интерфейса для всех приложений всей операционки. Когда есть подозрения на тормоза и проблемы, смотрите этот показатель. Критически важно, когда сервер брокера очень далеко. Например, для азиатских трейдеров и брокером в Европе.
Уже при 3% ретрансмитов можно сказать, что торговать нельзя. Запредельный уровень ретрансмитов дает плохой вайфай.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Новая версия платформы MetaTrader 5 build 2360: Расширение интеграции с SQLite
Renat Fatkhullin, 2020.04.06 12:33
Норма должна быть меньше 1%. И уже 3% сетевых потерь убивают low latency сервисы.
Например, у нас ретрансмиты 0.68 - 0.75% при заведомо бОльшем количестве пользователей (сейчас 17к в онлайне на MetaQuotes-Demo) . Причем мы обслуживаем весь мир, а не Москву/Россию.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
fxsaber, 2017.12.17 22:43
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
Renat Fatkhullin, 2017.12.17 23:03
Это статистика сетевого интерфейса всего компьютера, где Метатрейдер лишь один из пользователей. Не обязательно это связано с торговым сервером.
Общую статистику легко испортить веб-броузером после неудачного обращения на какой-то глючащий и далекий сайт. А можно и локальным вайфаем словить сетевой конфликт и получить десятки процентов ретрансмитов в случайные моменты времени.
При 20% ретрансмиттов в принципе не будет поддерживаться связь с торговым сервером, реконнекты будут постоянными и бесконечными. У терминала постоянное соединение и для него(для TCP/IP вернее) даже 3-5% ретрансмитов фатальны в задаче удержания долгих коннектов.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
Renat Fatkhullin, 2017.12.18 11:36
Учтите, что это техническая характеристика вашего локального TCP/IP стека, репорт о котором дает операционка, а не показатель качества конкретного соединения к торговым серверам. В него входит вся сетевая активность, включая системную/фоновую.
У торгового кластера заведомо связь качественная и мы штатно протоколируем массу параметров (это штатный функционал платформы), собирая минутные снапшоты с последующим анализом.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
Renat Fatkhullin, 2017.12.18 00:13
Проверил.
Ни на одном узле нашего демо-кластера, включая Азию, не было рестартов или повышения уровня ретрансмитов за весь день (да и в другие дни тоже). Все в норме от 0.5% до 1.5%.
Похоже, у меня очень много.
Сейчас полночь, котиры редко обновляются. Ретрансмиты увеличиваются на глазах. Хочется на VPS поставить Алерт на высокое значение > 1% для low latency торговли. Но с такими огромными значениями эта идея становится бессмысленной.
Что можно порекомендовать? Делать tracert до торгового сервера? Какая-нибудь программа мониторинга? В общем, как убедиться, что MT5 готов к low latency?
ЗЫ Как только котиры начинают шевелиться быстрее, показатель падает в разы.
Ретрансмиты.
Похоже, у меня очень много.
5-6 утра:
Дома (оптика, ETH в роутер, кабель в компьютер) - 8-19%, пинг 60-70
VPS в Нидерландах (в моменте 1 MT5 с 9 валютами/11 графиками) - 1.2-1.6%, пинг 3.7