Мы запускаем облачный сервис MQL5 Cloud Network! - страница 110

 
avik:

Пожалуйста, введите ограничения на минимально допустимый PR! Это ведь ни в какие ворота не лезит, когда 99% агентов выполняют задание за минуту, и потом оптимизатор ждёт ещё минут 20 пока несколько тормозных агентов просчитают свои задания!

Агенты, которые работают более, чем в два раза медленнее, чем в среднем по облаку, должны быть запрещены!

Жесть

средний PR облака, допустим 100; отключаем все ниже 50, средний PR стал, скажем 120, отключаем те, которые ниже 60 и т. п.; в итоге останутся агенты с PR  не менее чем в два раза меньше максимального PR в облаке (в пределе, но недостижимом).

А даже дохленький агент может выполнить какую-то задачу в переборе (или в форвард тестировании) без ущерба для других.

 
avik:

Пожалуйста, введите ограничения на минимально допустимый PR! Это ведь ни в какие ворота не лезит, когда 99% агентов выполняют задание за минуту, и потом оптимизатор ждёт ещё минут 20 пока несколько тормозных агентов просчитают свои задания!

Ограничения в распределении задач накладываемые на медленных агентов уже есть, но кроме генетики не связаны прямо с их рейтингом PR. В приведенном примере (20-ти кратное отличие от типичного времени выполнения задания) совершенно точно для "тормозных" агентов будут последствия, независимо от их рейтинга. Кроме того в подобных случаях происходит перераспределение заданий, т.е. задание забирается у откровенно медленного агента и передается на выполнение другому агенту. С повышением загрузки облака "тормозные" агенты будут вычисляться более эффективно, т.к. фактически лишь по результату работы можно точно оценить "тормознутость" агента и исключить его из работы. Соответственно с ростом загрузки будет расти качество предоставляемого пула агентов.

Агенты, которые работают более, чем в два раза медленнее, чем в среднем по облаку, должны быть запрещены!

Это слишком суровое ограничение, агенты с такой скоростью работы вполне способны принести пользу, особенно при полном переборе параметров.
 
Хорошо, используйте разные алгоритмы для полного перебора и для генетики. Для генетики медленные агенты - это СМЕРТЬ!
 
avik:
Хорошо, используйте разные алгоритмы для полного перебора и для генетики. Для генетики медленные агенты - это СМЕРТЬ!
Уже давно так сделано - при использовании генетики только агенты с PR более 100.
 
WChas:
Уже давно так сделано - при использовании генетики только агенты с PR более 100.

вы сами лично это давно использовали?

я вот попробовал и говорю вам, что в данный момент это UNUSABLE, по крайней мере для сложных задач, которые на моих собственных агентах считаются по 7 минут! так вот в облаке есть агенты, которые считают это чуть ли ни по часу, в результате генетическая оптимизация простаивает минимум по пол часа, в ожидании пока 1-2 тормозных агента вернут результат. мне приходится на каждой генерации, когда отработают все агенты кроме пары-тройки самых тормозных, отрубать облако, перекидывая их задачи на свои ядра. это, разумеется неудобно и занимает минимум в 2 раза больше времени, но это всё равно быстрее, чем ждать пока эти тормоза отработают.

 
я для себя решил проблему переходом с европейского облака на американское. там супер тормозных агентов нет. ура.
 
avik:

вы сами лично это давно использовали?

я вот попробовал и говорю вам, что в данный момент это UNUSABLE, по крайней мере для сложных задач, которые на моих собственных агентах считаются по 7 минут! так вот в облаке есть агенты, которые считают это чуть ли ни по часу, в результате генетическая оптимизация простаивает минимум по пол часа, в ожидании пока 1-2 тормозных агента вернут результат. мне приходится на каждой генерации, когда отработают все агенты кроме пары-тройки самых тормозных, отрубать облако, перекидывая их задачи на свои ядра. это, разумеется неудобно и занимает минимум в 2 раза больше времени, но это всё равно быстрее, чем ждать пока эти тормоза отработают.

да, неделю назад. Если в журнале выбрано "полные журналы оптимизации", то в них при генетической оптимизации отображались лишь агенты с пр > 100. Максимальный пр, который видел в журнале - это около 210. У самого пр около 150 на 8 агентах. На данный момент кто-то полностью их использует. В вашем случае предположу... что либо агента просто выключали из-за продолжительной загрузки процессора, либо шли, например, просто на перезагрузку, то есть просто прерывали работу агента. Соглашусь, что таймаут при неспособности агентом выполнить по тем или иным причинам задачу нужно сократить. С таким низким объемом заданий, как было до этого многие даже не готовы, что бы процессор работал под нагрузкой, мешая повседневной деятельности. Далеко не все компьютеры с агентами стоят "в уголочке" и используются только облаком.
 
отбой. прошу прощения. посмотрел "полные журналы оптимизации" и понял, что дело не в производительности агентов, а в некоторых экзотических сочетаниях параметров, которые приводят к очень долгому просчёту. сорри.
 
avik:
отбой. прошу прощения. посмотрел "полные журналы оптимизации" и понял, что дело не в производительности агентов, а в некоторых экзотических сочетаниях параметров, которые приводят к очень долгому просчёту. сорри.

Да, нужно быть готовым к тому, что при некоторых условиях или для некоторых торговых стратегий может сложиться такая ситуация, что один проход в тестере занимает секунды, а другой, с почти такими же параметрами, занимает минуты и десятки минут.

Разработчик эксперта должен постараться самостоятельно понять, какие условия или алгоритмы в его программе могут приводить к катасрофическому увеличению времени тестирования. Теоретически, вы можете предварительно прогнать грубую генетическую оптимизацию на локальных агентах (с большими шагами в параметрах), чтобы попробовать отловить такие потенцаильно опасные моменты. Но время выполнения каждого прохода нужно смотреть в логах тестера.

 

Добрый вечер.Облака "пропали".Обнаружил два дня назад.Неделю назад были точно.Конкретную дату получается не знаю.

Никакие настройки не менял.WIN 7 ,32 бит.Терминал Инста.Билд 574.Обновления не было еще.

 

В MQ все в порядке.Билд 581.

 

Удалось законнектится с терминала MQ (581) на сервера Инста. Облака сохранились и работают.

Значит вопрос ,почему не видно с оригинала Инста (574). 

Причина обращения: