Мы запускаем облачный сервис MQL5 Cloud Network! - страница 112
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Больше часа назад включил агентов. В моем профиле их нет. Хотел посмотреть PR. В MetaTesterAgents тестов 0, времени 0, трафик 11KB. Сервис работает?
Больше часа назад включил агентов. В моем профиле их нет. Хотел посмотреть PR. В MetaTesterAgents тестов 0, времени 0, трафик 11KB. Сервис работает?
Так как они получат задание, если PR не известен? Их нет в профиле. Раньше агенты в профиле появлялись сразу. Теперь не понятно что происходит. Пусть они не получают задания, но свои параметры должны показывать. Это очередной трюк МК. Таким образом они удерживают агентов в сети, даже те из них, которые не получать задания никогда (из-за ниского PR). Но зато на вкладочке будут числиться тысячи агентов, готовых к работе. Когда Вы (МК) начнете уважать своих пользователей?
Никакого неуважения нет.
Пока агент не получил ни одной задачи, он находится полностью в спящем состоянии, чтобы не тратить ни своих, ни чужих ресурсов. Он лишь изредка проверяет наличие задач у ближайшего клауд сервера. PR каждого агента известен всегда на момент обращения. Как только агент получит задачу и завершит ее, так сразу будет начислено заработанное и агент появится в списке регистраций.
Пока агент не заработал ничего, распределенная клауд сеть его не регистрирует на сайте (тоже экономит свои ресурсы), но всегда учитывает в живой очереди при раздаче задач. Раздача заданий всегда идет в режиме живой очереди, где любой агент равноправен кроме случая генетики.
Низкий PR учитывается только при использовании генетики - в остальных случаях задачи раздаются агентам даже с очень низкой производительностью. Чтобы в этом убедиться, достаточно запустить полный перебор и посмотреть в полные логи - у каждой задачи пишется PR агента, который ее выполнил.
На текущий момент более 12 тысяч агентов находятся в ждущем режиме. Задач на всех не хватает, что приводит к простою большей части расчетной сети.
На текущий момент более 12 тысяч агентов находятся в ждущем режиме. Задач на всех не хватает, что приводит к простою большей части расчетной сети.
Никакого неуважения нет.
...На текущий момент более 12 тысяч агентов находятся в ждущем режиме. Задач на всех не хватает, что приводит к простою большей части расчетной сети.
Я не знаю какой (не будем показывать пальцем) придумал разделить задачи на оптимизацию и форвардные тесты в разных режимах. Ведь даже пьяному ежику понятно, что если дать агенту одну задачу, т.е. за один прогон выполнить оба теста, то его производительность будет гораздо выше. Единственно, что ему придется, так это подсчитать два результата, т.е. один по оптимизируемому участку для генетики, а второй по форварду для проверки. Чтобы сэкономить ресурсы, необходимо останавливать агента, а не гонять по форварду только если на оптимизационной выборке эквити ниже начального баланса. А давать два разных задания разным агентам на одном и том же участке тестирования с одними и теми же входными параметрами - абсурд. Да и ни в какую не разбудишь потом этих самых агентов, чтобы они форвард после генетики просчитали, т.к. разработчики там что-то такое нахимичили, что не дождешься завершения тестирования.
Ну и потом, ведь все недовольны кроме разработчиков. И те кто предоставляют вычислительные ресурсы, поскольку их агенты простаивают и те кто тестируют торговые системы в тестере, поскольку если запустить генетический алгоритм, да еще и с форвардами, то замучаешься ждать пока он завершиться. Без генетического алгоритма максимум видел свыше трех тысяч агентов на пике и 0 на минимуме. А их там 12000 простаивают в очереди, как Вы сами констатируете. Без Clouds Network вообще невозможно оптимизировать, а как подключишь, то хоть стой, хоть падай - еле еле вошкается, хотя конечно заметно быстрее, чем без нее.
Цитирую: https://www.mql5.com/ru/forum/137422/page15
Главная задача гигантской сети - это СПАТЬ.
Главная задача гигантской вычислительной сети - РЕШАТЬ ЗАДАЧИ ПОЛЬЗОВАТЕЛЕЙ ЭТОЙ САМОЙ СЕТИ
Именно решать задачи, а не простаивать в спящем состоянии и не мурыжить пользователей, как предоставляющих вычислительне ресурсы, так и использующих эти самые вычислительные ресурсы.
Неужели сложно сделать хоть что нибудь, чтобы Cloud Network не спала, а работала? Ну если Вам так неймется, соберите себе корпоративную спящую вычислительную сеть для нужд MetaQuotes и наслаждайтесь, как она ни фига не делает. А нам такая не нужна.
Свободу агентам Сloud Network!
Именно решать задачи, а не простаивать в спящем состоянии и не мурыжить пользователей, как предоставляющих вычислительне ресурсы, так и использующих эти самые вычислительные ресурсы.
Неужели сложно сделать хоть что нибудь, чтобы Cloud Network не спала, а работала? Ну если Вам так неймется, соберите себе корпоративную спящую вычислительную сеть для нужд MetaQuotes и наслаждайтесь, как она ни фига не делает. А нам такая не нужна.
Не занимайтесь демагогией, пожалуйста.
Как-то нелепо объяснять принципы управления сложными системами и расжевывать простые понятия экономии. Мы разработали очень эффективную распределенную систему.
Да, сеть должна экономить свои ресурсы до тех пор, пока не появятся заказы на обработку. И она успешно справляется с этой задачей, обеспечивая разогрев (включение в работу) гигантской сети в пределах 30 секунд.
Еще раз повторю: сеть разогревается/поднимается настолько быстро, что Ваши неоднократные заявления "ха-ха, посмотрите, главная задача сети - спать!" являются глупостью.
MQL5 Cloud Network масштабируется линейно. При необходимости можем легко ее расширить до 500 000 или более агентов.
Гораздо более сложная задача - это привлечь заказчиков. И мы работаем над этим, добавляя новые механизмы сбора массивных данных с агентов и финальной отработки их в функции OnTesterFinalize. Это позволит запускать в сеть сложные расчетные задачи с постобработкой после последнего прохода.
...
Свободу агентам Сloud Network!
Всё. Революция. :)))
Не занимайтесь демагогией, пожалуйста.
Как-то нелепо объяснять принципы управления сложными системами и расжевывать простые понятия экономии. Мы разработали очень эффективную распределенную систему.
Да, сеть должна экономить свои ресурсы до тех пор, пока не появятся заказы на обработку. И она успешно справляется с этой задачей, обеспечивая разогрев (включение в работу) гигантской сети в пределах 30 секунд.
Еще раз повторю: сеть разогревается/поднимается настолько быстро, что Ваши неоднократные заявления "ха-ха, посмотрите, главная задача сети - спать!" являются глупостью.
MQL5 Cloud Network масштабируется линейно. При необходимости можем легко ее расширить до 500 000 или более агентов.
Гораздо более сложная задача - это привлечь заказчиков. И мы работаем над этим, добавляя новые механизмы сбора массивных данных с агентов и финальной отработки их в функции OnTesterFinalize. Это позволит запускать в сеть сложные расчетные задачи с постобработкой после последнего прохода.
Я не разбираюсь в принципах управления сложными системами, поскольку, я не разработчик этих самых систем, а пользователь и разбираться в них не обязан. Я занимаюсь автотрейдингом и оптимизировать даже весьма примитивную торговую систему на МТ5 очень муторно, даже при подключении к сети распределенных вычислений.
1. Потому что использую генетический алгоритм, а на нем сеть если и разогреется, то все равно не разгонится.
2. Потому что самым медленным является не генетика, а форвардные тесты после генетики.
Причина для того чтобы использовать генетику три:
1. Генетическому алгоритму вполне достаточно даже менее 10000 прогонов, чтобы найти экстремум для входных параметров ТС (зависит от торговой системе, поэтому говорю лишь про ту, которая у меня лично).
2. Если я отключу генетический алгоритм, то он все равно включится автоматом, т.к. дискретность входных параметров выходит за ограничения 1000000 проходов для 32 битной архитектуры.
3. Если генетический алгоритм даже и не включится, то все равно толку не будет, поскольку нужно просчитать 19 * 101^8 = 205742774069335219 проходов, а для этого никакой вычислительной сети не хватит, не говоря уже о времени вычислений. Про стоимость я вообще умолчу, т.к. дождаться завершения оптимизации все равно моим дальним потомкам не удастся.
Также у меня есть дополнительный тест для ТС, который прогоняет по входным параметрам для наиболее успешного форвардного теста по окрестностям. Там нужно бы конечно 11^8 = 214358881 проходов, но опять же из-за ограничений в 1000000 проходов, тест упрощенный и выполняется только для 11^5 = 161051 проходов. Здесь Сloud Network действительно и быстро разогревается и работает достаточно шустро, т.к. тестирование выполняется с полным перебором. Т.е. нареканий в таком режиме у меня нет (хотя хотелось бы и пошустрее, но в принципе и так устраивает вполне). Но я сомневаюсь, что кто-то еще прогоняет дополнительные тесты или вписывается со своей ТС в ограничения по количеству проходов, чтобы оптимизировать в режиме полного перебора.
Сейчас в основном задания получают те агенты, у которых PR > 100 (генетика).
Это в лишний раз подтверждает, что основное большинство задач оптимизации выполняются в режиме генетики, а не полного перебора, т.к. при полном переборе, как уже сообщали, подключаются агенты с любым PR, а для генетики с максимальными. А Cloud Network в режиме генетики, а особенно в режиме форвардов после генетики - это издевательство над автотрейдингом.