Бета-версия платформы MetaTrader 5 build 2055: Интеграция с Python и массовые улучшения в тестере стратегий - страница 26
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если оптимизация идет не только на локальном компьютере, то вероятно в этом может быть смысл, и то сомнительно, а если это на одном и том же компьютере, то это излишняя нагрузка.
Пожалуй это недоработка.
Вот опять наблюдаю. Осталось 7 заданий, а у агентов 38 заданий. Явно есть лишние.
В полных логах видно будет
Советник совсем не хочет работать с удаленными агентами. С локальными всё нормально.
Перезагружал компьютер с агентами и терминал.
В начале идет раздача, а потом в логе
Советник совсем не хочет работать с удаленными агентами. С локальными всё нормально.
Перезагружал компьютер с агентами и терминал.
В начале идет раздача, а потом в логе
У Вас на той стороне система соединение рвёт. Покажите логи удалённого агента
Прикладываю. Но, я так понимаю, что агент считает...
Прикладываю. Но, я так понимаю, что агент считает...
Судя по логам, агент работает на сильно загруженном компьютере. После выполнения очередной пачки и отсылки результатов он не успевает освободить поток для приёма следующей пачки. При неудаче приёма - разрыв коннекта с тем самым сообщением про occupied by another terminal.
Попробуйте уполовинить количество агентов. Мы проводили эксперименты на математических вычислениях на компьютере с гипертредингом - 10 физических ядер, 20 логических ядер. По времени нет никакой разницы, использовать 10 агентов или 20. На ксеоне фи с 68 физическими ядрами и 272 логическими лучшее время тоже было на чуть более половине логических ядер (речь идёт о чистой математике)
В итоге этой оптимзации все фреймы пришли?
Судя по логам, агент работает на сильно загруженном компьютере. После выполнения очередной пачки и отсылки результатов он не успевает освободить поток для приёма следующей пачки. При неудаче приёма - разрыв коннекта с тем самым сообщением про occupied by another terminal.
Попробуйте уполовинить количество агентов. Мы проводили эксперименты на математических вычислениях на компьютере с гипертредингом - 10 физических ядер, 20 логических ядер. По времени нет никакой разницы, использовать 10 агентов или 20. На ксеоне фи с 68 физическими ядрами и 272 логическими лучшее время тоже было на чуть более половине логических ядер (речь идёт о чистой математике)
В итоге этой оптимзации все фреймы пришли?
Это не логично, если обработка завершилась и произошла передача данных, то ядро разгрузилось же, а значит вполне можно продолжить обработку. Сейчас агенты заняты, но как освободятся я проверю эту гипотезу. Однако замечу, ведь этого не происходит с моим советником... может дело в тайм ауте - он сильно малый? Или прием новых заданий происходит не дождавшись получения результатов - тогда может быть затык трафика. Пока же не удалось провести оптимизацию вообще, что так же не логично, ведь если агенты отработали первую пачку и передали данные, то они свободны и должны бы были принять новое задание, спустя пару попыток, чего не происходит.
Замечу, что билд 2007 работал значительно стабильней - там потеря фреймов возникало только при обрыве соединения.
Это не логично, если обработка завершилась и произошла передача данных, то ядро разгрузилось же, а значит вполне можно продолжить обработку. Сейчас агенты заняты, но как освободятся я проверю эту гипотезу. Однако замечу, ведь этого не происходит с моим советником... может дело в тайм ауте - он сильно малый? Или прием новых заданий происходит не дождавшись получения результатов - тогда может быть затык трафика. Пока же не удалось провести оптимизацию вообще, что так же не логично, ведь если агенты отработали первую пачку и передали данные, то они свободны и должны бы были принять новое задание, спустя пару попыток, чего не происходит.
Замечу, что билд 2007 работал значительно стабильней - там потеря фреймов возникало только при обрыве соединения.
По сравнению с 2007 билдом в новом билде серьёзно уменьшен оверхед и увеличено быстродействие. Поэтому ядра нагружаются значительно больше, чем раньше.
Попробуйте уменьшить количество агентов и посмотрите, что будет
По сравнению с 2007 билдом в новом билде серьёзно уменьшен оверхед и увеличено быстродействие. Поэтому ядра нагружаются значительно больше, чем раньше.
Попробуйте уменьшить количество агентов и посмотрите, что будет
Может, и есть улучшения в теории, но на практике я столкнулся с обратной ситуацией, к сожалению.
Итак попробовал я оптимизацию вообще с одним агентом - результат аналогичный.
Не понятно, почему сервер считает, что нужно делать переконнект? Может там пинг сверх малый ожидается?
Добавлено:
При этом мой советник оптимизируется и даже на коротком задании не потерял фреймов
Может, и есть улучшения в теории, но на практике я столкнулся с обратной ситуацией, к сожалению.
Итак попробовал я оптимизацию вообще с одним агентом - результат аналогичный.
Не понятно, почему сервер считает, что нужно делать переконнект? Может там пинг сверх малый ожидается?
Добавлено:
При этом мой советник оптимизируется и даже на коротком задании не потерял фреймов
Спасибо за информацию.
Воспроизводим у себя и разбираемся
Спасибо за информацию.
Воспроизводим у себя и разбираемся
Рад помочь.
Для воспроизведения, я думаю, уместно использовать соединение не очень быстрое со стороны агента - сейчас у меня на отдачу примерно реальные 38-60 KB/s , а на прием 500-600 KB/S, при этом если агенты синхронно начнут передавать данные, то нужно пропускной канал делить на число агентов, я думаю что именно в этом одна из проблем. Ранее Ренат говорил, что много клиентов из Китая с медленным интернетом, поэтому, думаю, это актуальная проблема для воспроизведения.
Однако, потеря фреймов происходила и с другим агентом, где достаточно быстрый интернет.