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

 

в динамике: 

три дня назад упало до 150 вычислительных ядер и начислено ~$1

три дня после этого к-во вычислительных ядер увеличилось до 210 но стоимость за их ежедневную работу была на уровне ~$0.10

спасибо за внимание! 

 

Баланс не сходится

Смотрю одновременно на терминал и на cloud.mql5.com:


Временами на сайте число "агентов онлайн" падает до десятков (лично наблюдал аж 36 штук!), и это при том , что только у меня в этот момент включено порядка 20 в основном простаивающих агентов.

Есть предположение, что число "агентов онлайн" это на самом деле число агентов, получивших задания... Если так, предлагаю привести текст на сайте к более понятной формулировке и дополнить статистику числом доступных (в формулировке терминала) агентов и количеством заданий, ожидающих в очереди. Тогда, возможно, будет меньше вопросов типа "Почему счётчик проходов не растёт?"... К тому же, те участники, которые вступили в проект в надежде получить доход, смогут отключать часть мощностей исходя из складывающегося соотношения спрос/предложение.

 

Вообще конечно странно..если можно так сказать. У меня на работе пашет i7 - 8 агентов, пару квадов, три дуал-кора, до 540 билда был заработок порой около 0.2 - 0.3 уе в день, сейчас...0.01... это просто смешно. Если не сказать другими словами. А тормозов заметно прибавилось.

 
С переодической загрузкой процессора на коннекте уже разобрались - это PR принудительно рассчитывался, больше такого не будет.
 

Сегодня заметил не схождение заработанной суммы агентами в профиле во вкладке "агенты" за последние сутки (суммарно показывает $0.09) и начисленной суммы по концу дня ($0.01595), за предыдущий день было начислено еще меньше ($0.00271) (думал может предыдущий день тоже просуммировало в первом случае, оказалось - нет)

где все-таки правильная сумма показывается?

 
Renat:
С переодической загрузкой процессора на коннекте уже разобрались - это PR принудительно рассчитывался, больше такого не будет.

Кстати, про PR.

1) Учитывается ли он при диспетчеризации? Сейчас создаётся впечатление, что нет, т.к. самые PR-мощные агенты простаивают, в то время как середнячки более менее регулярно получают задания...

2) Какова методика определения PR? Т.е. получают ли агенты PR-задания индивидуально или "бригадой" (все агенты на машине одновременно). Первый вариант, вероятно, хорош только для нынешней ситуации недозагрузки. В ситуации высокой нагрузки "дутый" PR (когда на 1 ядро навешано по несколько агентов, поодиночке показывающих высокий результат) может дать неообоснованное преимущество в получении заданий агентами и тормоза для клиента...

 
За последние дни мы серьезно переделали механизмы работы клауд серверов ради экономичности:
  • Если для агента нет работы, то ему об этом сообщается на коннекте к серверу и агент не регистрируется как рабочий. Упор делается на снижение нагрузки.

  • Агенты активируются только на время работы с задачами. Показатель 'агентов онлайн' мы переименуем в 'агентов в работе'.

  • Показатель количества агентов сейчас не информативен, так как практически все агенты сидят в засаде и проявляются только под нагрузкой.

  • Сейчас из-за ограничения формулы распределения задач на терминале получается, что на каждом клауд сервере можно занять в среднем по 500-700 агентов даже если их в реальности несколько тысяч.

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

  • Работаем над повышением экономичности агентов: однократная загрузка истории, тотальное кеширование всех данных в зашифрованном виде в памяти.

  • Делаем правильную параллельную перераздачу задач, выделенных медленным агентам.

  • Полностью отключили агентов, у которых PR < 10, так как просто невозможно с ними работать.

  • При работе в генетике будет использоваться только один быстрейший клауд, причем задачи будут раздаваться агентам с высоким PR.

    Это связано с тем, что у генетики очень короткие популяции расчета и критически важна скорость их прохода. Пока одна популяция полностью не посчитана, следующая ждет.

За последние дни мы провели большое количество проверок и исправили ошибки.

На текущий момент облачная сеть работает успешно, расчеты задач идут быстро. Явных и критических ошибок практически нет. К следующему билду будет ряд указанных выше изменений, что еще повысит скорость расчетов, увеличит загрузку сети задачами при снижении системных расходов.

Общая просьба ко всем - не стесняйтесь, тестируйте свои стратегии в облаке - это дает реальное ускорение в десятки и сотни раз. Как минимум, можете использовать бонусные $2, которые даются каждому зарегистрировавшемуся на MQL5.com. К тому же, это не такое недорогое удовольствие.
 
Пока PR не учитывается в диспетчеризации явно - задачи раздаются всем пришедшим. В следующей версии PR явно будет учитываться при расчете в генетике, где скорость ответа критически важна.

Каждый агент независим как во время расчета задач, так и во время вычисления PR. Но в следующем билде все агенты из одного *.exe образа будут использовать единое хранилище истории чартов.
 

хотелось бы привлекать пользователей в облоко

так и вижу в конце этой строчки свою реф ссылку :) 
https://cloud.mql5.com/ru

такое возможно ?

Распределенные вычисления в сети MQL5 Cloud Network
Распределенные вычисления в сети MQL5 Cloud Network
  • cloud.mql5.com
Заработать деньги, продавая мощности своего компьютера для сети распределенных вычислений MQL5 Cloud Network
 

Присоединяюсь к мнению papaklass:

проблемы с облачным тестированием (по крайней мере, для мультивалютников), существуют.

Прогнал тест с фиктивным параметром (задал 100 проходов). Результат (должна быть прямая линия):


 

Лог тестера и отчет оптимизатора прилагаются. 

PS. xml пришлось переименовать, т.к. его нет в списке типов для закачки. 

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