Мы запускаем облачный сервис MQL5 Cloud Network! - страница 151
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Спасибо! тема для меня - новая. Вроде уяснил тонкие моменты.
Вот за эту оптимизацию ориентировочно с меня снимут 20 кредитов. Раньше было значительно дешевле. И цифры в отчете вызывают вопросы. Из 16441 проходов облако, за которое я заплачу, выполнило 16440. Разница в один проход. А что же тогда выполняли мои агенты (локальные и удаленные)?
Началась пред-чемпионатовская лихорадка, сеть нагрузили, и повылазили новые глюки.
Ну, хоть так ее проверят ) Хотя, конечно, не хотелось бы за счет пользователей..
Сетевой рендер для 3d MAX, affter effects. Слышал что 3д-максеры бывают рендерят проекты по несколько суток.
возможно такая реализация в этой облачной сети?
Здравствуйте!
Адресую данное сообщение разработчикам MQL5 Cloud Network.
Обратите внимание на следующие скриншоты:
Агенты работали не 49 минут как показано на картинке, а по несколько часов (больше 18 точно) в течение суток каждый день. Поэтому платежные расчеты произведены неверно, ибо за каждый час должно было быть по 0.01 как минимум, а там и близко этого нет.
Также не совпадает по картинкам общее кол-во пройденных тестов.
И ещё такой нюанс. Если PR агента высокий, то конечно он должен зарабатывать больше, чем стандартный. Однако поскольку он выполняет задания быстрее, то и времени тратит меньше, а время учтено в формуле расчетов при перемножении, таким образом уменьшая стоимость работы агентов вместо роста.
Считаю, что при расчетах необходимо учитывать количество выполненных заданий, иначе смысла предоставлять агентов с высоким PR нет никакого.
Агенты работали не 49 минут как показано на картинке, а по несколько часов (больше 18 точно) в течение суток каждый день. Поэтому платежные расчеты произведены неверно, ибо за каждый час должно было быть по 0.01 как минимум, а там и близко этого нет.
Представьте доказательства работы по несколько часов, пожалуйста. Например, просуммировав все старты-стопы заданий по логам агентов.
То, что агент запущен, совсем не означает, что он работает. Пока задач нет, он их ждет и не потребляет ресурсов.
Представьте доказательства работы по несколько часов, пожалуйста. Например, просуммировав все старты-стопы заданий по логам агентов.
То, что агент запущен, совсем не означает, что он работает. Пока задач нет, он их ждет и не потребляет ресурсов.
Ренат, подавал заявку в СД #559392.
Вот кусок лога:
Собирал статистику целую неделю: агенты работали по 10 минут или около того, потом останавливаются заказчиком, а оплата не проходила. Аналогичная ситуация была с расхождениями в проходах между тестером и профилем, причем в профиле больше чем в менеджере.
Решение будет по этой заявке?
Собирал статистику целую неделю: агенты работали по 10 минут или около того, потом останавливаются заказчиком, а оплата не проходила. Аналогичная ситуация была с расхождениями в проходах между тестером и профилем, причем в профиле больше чем в менеджере.
Решение будет по этой заявке?
Я ответил с сервисдеске.
С учетом того, что у Вас агенты работают стабильно и исполнено больше сотни тысяч задач, то некоторые единичные случаи, когда расчет задачи прерывается и серверу не возвращается решение, вполне нормальны/ожидаемы. Если задача по какой-либо причине не вернула решение, то клауд не может засчитать эту работу.
В представленных логах видно, что расчет одной задачи занимает очень много времени и вполне возможно, что это такой затратный эксперт, который к тому же может содержать логические ошибки и зацикливания при разных вариантах входных параметров.
Я ответил с сервисдеске.
Спасибо.
Если задача по какой-либо причине не вернула решение, то клауд не может засчитать эту работу.
А это не есть хорошо. Поставщик агентов не виноват, что код отправленный его агенту был не корректен. Ресурс был использован, а оплата не проходила. Ведь в это время агент мог выполнять другие "нормальные" оплачиваемые задачи.
Может нужно подумать более детально над методом контроля работы/зацикливания агента?
А это не есть хорошо. Поставщик агентов не виноват, что код отправленный его агенту был не корректен. Ресурс был использован, а оплата не проходила. Ведь в это время агент мог выполнять другие "нормальные" оплачиваемые задачи.
Может нужно подумать более детально над методом контроля работы/зацикливания агента?
Тут есть и обратная проблема, что на части агентов задачи просто тормозятся/глючат/прерываются из-за недостатка ресурсов и получается, что заказчик оплачивает работу без получения результатов.
Со своей стороны мы провели несколько раундов тюнинга и защиты сети от слабых агентов, на лету собираем статистику потребляемых ресурсов каждым экспертом и стараемся распределять задачи на агентов с соответствующими возможностями. Кроме того, мы автоматически умеем блокировать совсем ошибочных экспертов и отключаем их от приема в сеть. В результате мы свели количество проблем до минимума, но все равно продолжим работу в этом направлении.
Представьте доказательства работы по несколько часов, пожалуйста. Например, просуммировав все старты-стопы заданий по логам агентов.
То, что агент запущен, совсем не означает, что он работает. Пока задач нет, он их ждет и не потребляет ресурсов.
Ренат!
Просуммировать, конечно, можно. Время жалко, скурпулезная работа, столько выдержек перемолотить, складывая все по минутам. Поэтому ладно, оставим пока как есть, учитывая, что несовпадения были и у других, и вы этим занимаетесь.
Однако вопрос по учету кол-ва проходов при расчете стоимости услуг агента остается в силе.
Встречается много вот таких вещей, когда время потрачено, исторических данных нет и задание отклоняется: