Бета-версия платформы MetaTrader 5 build 2055: Интеграция с Python и массовые улучшения в тестере стратегий - страница 26

Новый комментарий
 
Aleksey Vyazmikin:

Если оптимизация идет не только на локальном компьютере, то вероятно в этом может быть смысл, и то сомнительно, а если это на одном и том же компьютере, то это излишняя нагрузка.

Пожалуй это недоработка.

Вот опять наблюдаю. Осталось 7 заданий, а у агентов  38 заданий. Явно есть лишние.


 
Slava:
В полных логах видно будет

Советник совсем не хочет работать с удаленными агентами. С локальными всё нормально.

Перезагружал компьютер с агентами и терминал.

В начале идет раздача, а потом в логе

occupied by another terminal
Файлы:
20190619_.zip  4 kb
 
Aleksey Vyazmikin:

Советник совсем не хочет работать с удаленными агентами. С локальными всё нормально.

Перезагружал компьютер с агентами и терминал.

В начале идет раздача, а потом в логе

У Вас на той стороне система соединение рвёт. Покажите логи удалённого агента
 
Slava:
У Вас на той стороне система соединение рвёт. Покажите логи удалённого агента

Прикладываю. Но, я так понимаю, что агент считает...

Файлы:
20190619_ag.zip  10 kb
 
Aleksey Vyazmikin:

Прикладываю. Но, я так понимаю, что агент считает...

Судя по логам, агент работает на сильно загруженном компьютере. После выполнения очередной пачки и отсылки результатов он не успевает освободить поток для приёма следующей пачки. При неудаче приёма - разрыв коннекта с тем самым сообщением про occupied by another terminal.

Попробуйте уполовинить количество агентов. Мы проводили эксперименты на математических вычислениях на компьютере с гипертредингом - 10 физических ядер, 20 логических ядер. По времени нет никакой разницы, использовать 10 агентов или 20. На ксеоне фи с 68 физическими ядрами и 272 логическими лучшее время тоже было на чуть более половине логических ядер (речь идёт о чистой математике)

В итоге этой оптимзации все фреймы пришли?

 
Slava:

Судя по логам, агент работает на сильно загруженном компьютере. После выполнения очередной пачки и отсылки результатов он не успевает освободить поток для приёма следующей пачки. При неудаче приёма - разрыв коннекта с тем самым сообщением про occupied by another terminal.

Попробуйте уполовинить количество агентов. Мы проводили эксперименты на математических вычислениях на компьютере с гипертредингом - 10 физических ядер, 20 логических ядер. По времени нет никакой разницы, использовать 10 агентов или 20. На ксеоне фи с 68 физическими ядрами и 272 логическими лучшее время тоже было на чуть более половине логических ядер (речь идёт о чистой математике)

В итоге этой оптимзации все фреймы пришли?

Это не логично, если обработка завершилась и произошла передача данных, то ядро разгрузилось же, а значит вполне можно продолжить обработку. Сейчас агенты заняты, но как освободятся я проверю эту гипотезу. Однако замечу, ведь этого не происходит с моим советником... может дело в тайм ауте - он сильно малый? Или прием новых заданий происходит не дождавшись получения результатов - тогда может быть затык трафика. Пока же не удалось провести оптимизацию вообще, что так же не логично, ведь если агенты отработали первую пачку и передали данные, то они свободны и должны бы были принять новое задание, спустя пару попыток, чего не происходит.

Замечу, что билд 2007 работал значительно стабильней - там потеря фреймов возникало только при обрыве соединения.

 
Aleksey Vyazmikin:

Это не логично, если обработка завершилась и произошла передача данных, то ядро разгрузилось же, а значит вполне можно продолжить обработку. Сейчас агенты заняты, но как освободятся я проверю эту гипотезу. Однако замечу, ведь этого не происходит с моим советником... может дело в тайм ауте - он сильно малый? Или прием новых заданий происходит не дождавшись получения результатов - тогда может быть затык трафика. Пока же не удалось провести оптимизацию вообще, что так же не логично, ведь если агенты отработали первую пачку и передали данные, то они свободны и должны бы были принять новое задание, спустя пару попыток, чего не происходит.

Замечу, что билд 2007 работал значительно стабильней - там потеря фреймов возникало только при обрыве соединения.

По сравнению с 2007 билдом в новом билде серьёзно уменьшен оверхед и увеличено быстродействие. Поэтому ядра нагружаются значительно больше, чем раньше.

Попробуйте уменьшить количество агентов и посмотрите, что будет

 
Slava:

По сравнению с 2007 билдом в новом билде серьёзно уменьшен оверхед и увеличено быстродействие. Поэтому ядра нагружаются значительно больше, чем раньше.

Попробуйте уменьшить количество агентов и посмотрите, что будет

Может, и есть улучшения в теории, но на практике я столкнулся с обратной ситуацией, к сожалению.

Итак попробовал я оптимизацию вообще с одним агентом - результат аналогичный.

2019.06.20 20:47:38.024 Tester  register MQL5.community account and use MQL5 Cloud Network to speed up optimizations
2019.06.20 20:47:38.055 Tester  set "Custom max" as optimization criterion for mathematical calculations
2019.06.20 20:47:38.086 Experts optimization frame expert MathExpertFrames (GAZR Splice,H1) processing started
2019.06.20 20:47:38.164 Tester  Experts\MathExpertFrames.ex5 math calculations test means no history and no symbol info for GAZR Splice
2019.06.20 20:47:38.164 Tester  complete optimization started
2019.06.20 20:47:38.164 Tester  tester_no_cache property used
2019.06.20 20:47:38.195 FX_08   connecting to ***.***.***.***:2000
2019.06.20 20:47:38.320 FX_08   connected
2019.06.20 20:47:38.461 FX_08   authorized (agent build 2085)
2019.06.20 20:47:38.461 FX_08   pass 0 (batch of 2601 tasks) started
2019.06.20 20:47:41.148 FX_08   common synchronization completed
2019.06.20 20:48:41.624 FX_08   connection closed
2019.06.20 20:48:41.640 FX_08   2601 optimization passes returned to queue as not processed
2019.06.20 20:48:41.640 FX_08   connecting to ***.***.***.***:2000
2019.06.20 20:48:44.702 FX_08   connected
2019.06.20 20:48:44.889 FX_08   authorized (agent build 2085)
2019.06.20 20:48:44.889 FX_08   pass 0 (batch of 2601 tasks) started
2019.06.20 20:48:47.282 FX_08   common synchronization completed
2019.06.20 20:49:41.579 FX_08   connection closed
2019.06.20 20:49:41.579 FX_08   2601 optimization passes returned to queue as not processed
2019.06.20 20:49:41.579 FX_08   connecting to ***.***.***.***:2000
2019.06.20 20:49:41.642 FX_08   connected
2019.06.20 20:49:41.767 FX_08   occupied by another terminal
2019.06.20 20:50:03.171 Tester  optimization finished, total passes 0
2019.06.20 20:50:03.171 Statistics      optimization done in 2 minutes 25 seconds
2019.06.20 20:50:03.171 Tester  stopped by user

Не понятно, почему сервер считает, что нужно делать переконнект? Может там пинг сверх малый ожидается?

Добавлено:

При этом мой советник оптимизируется и даже на коротком задании не потерял фреймов

2019.06.20 20:56:55.308 Tester  register MQL5.community account and use MQL5 Cloud Network to speed up optimizations
2019.06.20 20:56:55.792 Tester  set "Custom max" as optimization criterion for mathematical calculations
2019.06.20 20:56:57.169 Experts optimization frame expert Tree_Brut_v_02_03_01p4 (GAZR Splice,H1) processing started
2019.06.20 20:56:58.356 Tester  Experts\Tree_Brut_v_02_03_01p4.ex5 math calculations test means no history and no symbol info for GAZR Splice
2019.06.20 20:56:58.356 Tester  complete optimization started
2019.06.20 20:56:58.824 FX_08   connecting to ***.***.***.***:2000
2019.06.20 20:56:58.870 FX_08   connected
2019.06.20 20:56:59.043 FX_08   authorized (agent build 2085)
2019.06.20 20:56:59.043 FX_08   pass 0 (batch of 5 tasks) started
2019.06.20 20:58:25.467 FX_08   common synchronization completed
2019.06.20 21:01:06.611 FX_08   pass 0 returned result 1001000.00 in 0:02:24.519
2019.06.20 21:03:46.479 FX_08   pass 1 returned result 1001000.00 in 0:02:34.118
2019.06.20 21:06:15.461 FX_08   pass 2 returned result 1001000.00 in 0:02:30.717
2019.06.20 21:08:45.098 FX_08   pass 3 returned result 1001000.00 in 0:02:32.398
2019.06.20 21:11:15.272 FX_08   pass 4 returned result 1001000.00 in 0:02:31.636
2019.06.20 21:11:15.272 Tester  optimization finished, total passes 5
2019.06.20 21:11:15.288 Statistics      optimization done in 14 minutes 17 seconds
2019.06.20 21:11:15.288 Statistics      shortest pass 0:02:24.519, longest pass 0:02:34.118, average pass 0:02:30.677
2019.06.20 21:11:15.288 Statistics      5000 frames (1.96 Mb total, 412 bytes per frame) received
2019.06.20 21:11:15.288 Statistics      local 0 tasks (0%), remote 5 tasks (100%), cloud 0 tasks (0%)
2019.06.20 21:11:15.366 Tester  5 new records saved to cache file 'tester\cache\Tree_Brut_v_02_03_01p4.30.177AC00E8EC9036BAF7822F1D8E0D02B.opt'
2019.06.20 21:11:15.366 FX_08   connection closed
 
Aleksey Vyazmikin:

Может, и есть улучшения в теории, но на практике я столкнулся с обратной ситуацией, к сожалению.

Итак попробовал я оптимизацию вообще с одним агентом - результат аналогичный.

Не понятно, почему сервер считает, что нужно делать переконнект? Может там пинг сверх малый ожидается?

Добавлено:

При этом мой советник оптимизируется и даже на коротком задании не потерял фреймов

Спасибо за информацию.

Воспроизводим у себя и разбираемся

 
Slava:

Спасибо за информацию.

Воспроизводим у себя и разбираемся

Рад помочь.

Для воспроизведения, я думаю, уместно использовать соединение не очень быстрое со стороны агента - сейчас у меня на отдачу примерно реальные 38-60 KB/s , а на прием 500-600 KB/S, при этом если агенты синхронно начнут передавать данные, то нужно пропускной канал делить на число агентов, я думаю что именно в этом одна из проблем. Ранее Ренат говорил, что много клиентов из Китая с медленным интернетом, поэтому, думаю, это актуальная проблема для воспроизведения.

Однако, потеря фреймов происходила и с другим агентом, где достаточно быстрый интернет.
1...1920212223242526272829
Новый комментарий
Причина обращения: