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

 
icas:
 До автоматического обновления на 2-х адерном процессоре был только один агент, после обновления до v.607 автоматически появилось два агента.

Сам агент себя не (до)инсталлирует автоматически - у него нет такого поведения.

Проверьте журналы в каталоге Каталог-данных/Tester/Manager/Logs, в них должна быть вся информация об инсталляции и деинсталляции агентов.

FR      0       Startup 15:05:00        MetaTester 5 x64 build 600 (01 Mar 2012)
PF      0       Startup 15:05:00        initialization finished
JJ      0       Service 15:05:06        Service 'MetaTester-1' successfully installed
KL      0       Service 15:05:06        Service 'MetaTester-1' start initialized
KK      0       Service 15:05:09        Service 'MetaTester-1' started in 2933 ms
JR      0       Service 15:05:09        Service 'MetaTester-2' successfully installed
KE      0       Service 15:05:09        Service 'MetaTester-2' start initialized
RR      0       Service 15:05:12        Service 'MetaTester-2' started in 2964 ms
IJ      0       Service 15:05:20        Service 'MetaTester-1' stop initialized
PQ      0       Service 15:06:11        Service 'MetaTester-1' stopped in 50498 ms
FJ      0       Service 15:06:11        Service 'MetaTester-1' successfully uninstalled
GE      0       Service 15:06:11        Service 'MetaTester-2' stop initialized
KM      0       Service 15:06:14        Service 'MetaTester-2' stopped in 3011 ms
JE      0       Service 15:06:14        Service 'MetaTester-2' successfully uninstalled
 
kpu3uc:
(интересно, я туда куда надо пишу?)

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

Да, мы работаем на детальным контролем ресурсов (диск+память) перед включением OpenCL в облаках. Для нас важно сделать систему, которая работает очень аккуратно с ресурсами.

Задача трудная, но процентов на 80 грубые методы защиты помогут.

 
Ну так всёже, ответьте мне на мои вопросы уважаемые разработчики?
 
На аналогичные вопросы уже неоднократно давались ответы.

Чтобы получить ответ на вопрос о времени прохода, надо смотреть на символ и количество тиков. Наверняка там что-то на уровне 50 000 000 тиков. Если это кросс-курс, то на самом деле объем моделирования удвояется, так как тестер вынужден неявно моделировать курс пересчета в валюту депозита.

Сейчас в МТ5 нельзя считать, что режим по ценам открытия подобен аналогичному в МТ4. В МТ5 всегда используется детальный метод моделирования всех промежуточных тиков. Это видно по количеству тиков в финальном отчете.

При использовании режима генетики надо понимать принцип тестирования на основе коротких популяций. То есть, максимальный коэффициент масштарирования на генетике не больше 256, а обычно на уровне 64. Почитайте статьи о генетике, пожалуйста.
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
  • www.mql5.com
Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете - Документация по MQL5
 

Renat:
 ... объем моделирования удвояется ...

Пардон, наверно удваивается. Или так смысл глубже? ))
 
Renat:
На аналогичные вопросы уже неоднократно давались ответы.

Чтобы получить ответ на вопрос о времени прохода, надо смотреть на символ и количество тиков. Наверняка там что-то на уровне 50 000 000 тиков. Если это кросс-курс, то на самом деле объем моделирования удвояется, так как тестер вынужден неявно моделировать курс пересчета в валюту депозита.

Сейчас в МТ5 нельзя считать, что режим по ценам открытия подобен аналогичному в МТ4. В МТ5 всегда используется детальный метод моделирования всех промежуточных тиков. Это видно по количеству тиков в финальном отчете.

При использовании режима генетики надо понимать принцип тестирования на основе коротких популяций. То есть, максимальный коэффициент масштарирования на генетике не больше 256, а обычно на уровне 64. Почитайте статьи о генетике, пожалуйста.
Вы судя по всему не полностью прочли мои вопросы. Вопрос основной был по облаку. Оно не работает. А вернее каждый раз зависает в конце каждого ген.прохода. Повторюсь - когда облако будет полноценно работать без зависаний?
 
Я прочел вопросы, просто не ответил развернуто. Облако вынужденно ждет завершения кратких серий проходов по 64-256 штук из-за самой природы генетического анализа. Чтобы перейти к следующему поколению, надо завершить предыдущее.
 
Агенты регистрируются в личном профайле только после исполнения первой задачи. Пока агент не отработал ни одной задачи, он и его статистика закономерно не регистрируются.

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

Что за истерика? Этот вопрос неоднократно освещался.
 
Renat:
Я прочел вопросы, просто не ответил развернуто. Облако вынужденно ждет завершения кратких серий проходов по 64-256 штук из-за самой природы генетического анализа. Чтобы перейти к следующему поколению, надо завершить предыдущее.
Я понимаю что оно ждёт. И все это понимют. Вопрос в том что это ожидание дальше не сдвигается. Расчёт останавливается полностью из-за того что некоторые удалённые агенты в облаке не возвращают результат. Поэтому я и задал вопрос когда это дело пофиксят? Неужели так сложно реализовать распределение "умерших" задач по другим агентам? С октября ведь уже запустили и всё никак не работает. Зато деньги у вас всегда чётко взимаются без проблем. А по сути услугу то мы не получаем в нужном объёме из-за недоработки.
 
Renat:
Агенты регистрируются в личном профайле только после исполнения первой задачи. Пока агент не отработал ни одной задачи, он и его статистика закономерно не регистрируются.

...

Откуда тогда берутся записи следующего вида (PR 0, задачи 0, время создания совпадает со временем активности в пределах минуты):

 
Intel Celeron E3400 @ 2.60GHz, 2013MB
S........ xxx.yyy.zzz.242000.002012.03.112012.03.11