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

 
stringo:

"Already procesed by other agent' означает, что диспетчер оптимизации ближе к концу расчётов (особенно в при генетической оптимизации в конце расчёта очередной популяции), при том, что локальные агенты уже простаивают, поручил локальным агентам выполнить некоторые задания, уже отданные в облако.

Такое решение позволило минимизировать время ожидания результатов от медленных агентов

В облаке такое работает, а с удаленными нет.

Много тестировал и получил результат: когда на генетике локальные агенты уже отработали, удаленные еще считают. Потом, когда удаленные закончили снова включаются все агенты.

 
stringo:

"Already procesed by other agent' означает, что диспетчер оптимизации ближе к концу расчётов (особенно при генетической оптимизации в конце расчёта очередной популяции), при том, что локальные агенты уже простаивают, поручил локальным агентам выполнить некоторые задания, уже отданные в облако.

Нет, версия не подходит. Локальные агенты были изначально отключены в силу своей медлительности. Во-вторых, я уже написал, что "в графе "Задания/Выполнено" указано "510/524" - это говорит о том, что 14 заданий было выполнено именно в облаке сверх того количества проходов, которое было задано этому же  облаку "MQL5 Cloud Europe 2". И центы снимались уж точно не за работу локальных агентов :)
 
stringo:

"Already procesed by other agent' означает, что диспетчер оптимизации ближе к концу расчётов (особенно в при генетической оптимизации в конце расчёта очередной популяции), при том, что локальные агенты уже простаивают, поручил локальным агентам выполнить некоторые задания, уже отданные в облако.

Такое решение позволило минимизировать время ожидания результатов от медленных агентов

Хорошая задумка
 
Yedelkin:
Нет, версия не подходит. Локальные агенты были изначально отключены в силу своей медлительности. Во-вторых, я уже написал, что "в графе "Задания/Выполнено" указано "510/524" - это говорит о том, что 14 заданий было выполнено именно в облаке сверх того количества проходов, которое было задано этому же  облаку "MQL5 Cloud Europe 2". И центы снимались уж точно не за работу локальных агентов :)

510/524 - это несколько из другой оперы. Клауд-сервер внутри себя может определять медленных агентов и перераспределять их задания.

 
fyords:

В облаке такое работает, а с удаленными нет.

Много тестировал и получил результат: когда на генетике локальные агенты уже отработали, удаленные еще считают. Потом, когда удаленные закончили снова включаются все агенты.

С удалёнными такое тоже будет работать. Надо только механизм как следует отладить.
 
stringo:

510/524 - это несколько из другой оперы. Клауд-сервер внутри себя может определять медленных агентов и перераспределять их задания.

Понятно. Значит, всё-таки клауд-сервер перераспределяет задания, увеличивая их общее количество для клиента. Т.е. моё изначальное предположение верно: "там втихаря идут параллельные прогоны, а пользователь всё равно их оплачивает".
 
Yedelkin:
Понятно. Значит, всё-таки клауд-сервер перераспределяет задания, увеличивая их общее количество для клиента. Т.е. моё изначальное предположение верно: "там втихаря идут параллельные прогоны, а пользователь всё равно их оплачивает".
Если бы не было таких дублирующих прогонов, то пользователь ждал бы неизвестно сколько долго медленных или "заткнувшихся" агентов (с соответствующей оплатой). А так, по концу оптимизации все оставшиеся занятые агенты тут же прекращают свою работу. То есть, не факт, что при таком перевыполнении заданий Вы платите больше, чем без него.
 
stringo:... пользователь ждал бы неизвестно сколько долго медленных или "заткнувшихся" агентов (с соответствующей оплатой).

Насчёт оплаты. Разве размер платы за использование облачного агента не поставлен в прямую зависимость от его производительности? Т.е., если агент с PR=100 оказался медленным или заткнулся, то владелец такого агента всё равно получает за час его работы вознаграждение исходя из часовой стоимости работы агента с PR=100?

 
Yedelkin:

Насчёт оплаты. Разве размер платы за использование облачного агента не поставлен в прямую зависимость от его производительности? Т.е., если агент с PR=100 оказался медленным или заткнулся, то владелец такого агента всё равно получает за час его работы вознаграждение исходя из часовой стоимости работы агента с PR=100?

Учитывайте, что время просчета, которое показывается на терминале, является полным временем возврата ответа от конкретного агента.

Полное время ответа агента = время на синхронизацию истории + время реального расчета эксперта. Клауд сервер учитывает только реальное время, потраченное на расчет и не учитывает время синхронизации.

То есть, когда Вы видите ответ 500 сек, это означает, что скорее всего 450 секунд было потрачено на выкачку истории, а 50 секунд - на расчет. Когда видите тормозные ответы от мощных агентов, это означает, что они находились в состоянии синхронизации. На следующих проходах эти агенты уже начинают работать нормально.


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

 
Yedelkin:

Насчёт оплаты. Разве размер платы за использование облачного агента не поставлен в прямую зависимость от его производительности? Т.е., если агент с PR=100 оказался медленным или заткнулся, то владелец такого агента всё равно получает за час его работы вознаграждение исходя из часовой стоимости работы агента с PR=100?

Напрямую зависит.

Я не зря написал: "заткнувшиеся" агенты. У агента может быть приличный PR, но при этом проблемы со связью. В нашем процессе связь - самое тонкое место. Процесс передачи данных может занять неизвестное количество времени; с агентом может уже не быть связи, а диспетчер заданий ждёт от него результата, полагая, что агент ещё живой. Очень много разных ситуаций может быть, поэтому лучше лишний раз перевыполнить задание, а не ждать

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