MetaTrader 5 Strategy Tester и MQL5 Cloud Network - страница 30

Новый комментарий
 
Renat:

Боюсь, что при 24 агентах на 8 ядрах (4 по сути + гипертрейдинг) Вы всю производительность процессора потратите на обеспечение инфраструктуры.

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

   Все понял выставил 8 советников. Спасибо за информацию!
 
papaklass:

Давно не пользовался облаком. Решил использовать при подборе параметров. Работа облака ПРИЯТНО удивила.

Если долго шлифовать систему распределенной сети, то результат получается хороший.
 
Renat:
Если долго шлифовать систему распределенной сети, то результат получается хороший.
PF      0       MQL5 Cloud Europe 2     00:24:16        genetic pass (264, 0, 188) started
JL      0       MQL5 Cloud Europe 2     00:29:07        connection closed
ID      0       MQL5 Cloud Europe 2     00:29:07        connecting to 3.agents.mql5.com:443
GL      0       Tester  00:29:07        cloud server MQL5 Cloud Europe selected for genetic computation
KO      0       MQL5 Cloud Europe 2     00:29:07        connected
JP      0       MQL5 Cloud Europe 2     00:29:10        authorized (server build 696)
RG      0       Tester  00:30:11        Best result 32.12073652718463 produced at generation 20. Next generation 21
KJ      0       MQL5 Cloud Europe       00:30:11        common synchronization completed
GN      0       MQL5 Cloud Europe       01:57:24        connection closed
CI      0       MQL5 Cloud Europe 2     01:57:24        connection closed
MS      3       Tester  01:57:24        genetic pass (21, 285) not processed and added to task queue
II      3       Tester  01:57:24        genetic pass (21, 498) not processed and added to task queue
PO      3       Tester  01:57:24        genetic pass (21, 499) not processed and added to task queue
GQ      0       MQL5 Cloud Europe       01:57:24        genetic pass (21, 285) returned to queue
NF      0       Tester  01:57:24        genetic pass (21, 499) already processed
KN      0       Tester  01:57:24        genetic pass (21, 498) already processed
OJ      0       Core 1  01:57:24        genetic pass (285, 0, 1) started
PS      0       Core 2  01:57:24        genetic pass (285, 0, 1) started
были выданы задания локальным + удалённым агентам + клауд. Подвис один проход на клауде. Спустя почти полтора часа ожидания, отключил клауд - задачи перебросились на локальные агенты. Скорость прогона - в пределах 1-3-х минут:
DP      0       Core 1  02:14:59        genetic pass (23, 256) returned result 4.45 in 45 sec
LH      0       Core 1  02:14:59        genetic pass (273, 0, 1) started
CP      0       Core 5  02:14:59        genetic pass (23, 260) returned result 2.64 in 46 sec
OH      0       Core 5  02:14:59        genetic pass (274, 0, 1) started
PS      0       Core 6  02:15:01        genetic pass (23, 261) returned result 3.37 in 48 sec
HH      0       Core 6  02:15:01        genetic pass (278, 0, 1) started
KQ      0       Core 8  02:15:03        genetic pass (23, 264) returned result -0.01 in 50 sec
CG      0       Core 8  02:15:03        genetic pass (279, 0, 1) started
PP      0       Core 2  02:15:06        genetic pass (23, 257) returned result -0.01 in 52 sec
DG      0       Core 2  02:15:06        genetic pass (280, 0, 1) started
NP      0       Core 3  02:15:07        genetic pass (23, 258) returned result -0.01 in 53 sec

В общем, на полтора часа никак не тянет.

P. S. Включил клауд на "лету". Из-за пропадания интернета, отвалились удалённые агенты. Потом не хотели подключаться (состаяние autorized; не подключались как минимум два генетических поколения) - видимо тестер решил, что задач и на клауд хватит, а халявные агенты пусть отдохнут. Отключил "клауд". Подключились удалённые агенты. Включил клауд. Ну и в итоге получил подвисание.

 

Сеть таки нужно немного допилить, чтобы небыло подобных ситуаций (например, запоминать максимальное время прохода и если ожидание прохода длится в 2 раза дольше максимального времени прохода - запустить тот же процесс на лучшем ядре из локальных (или удалённых)).

+ нужно доработать TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) 

+ скорость генетики зависит от скорости самого слабого ядра - если у моих ядер PR - 160-180, а задачи в cloud раздаются ядрам вплоть до 100. В итоге, каждое поколение, мои ядра вынуждены простаивать существенное время и ожидать ответов от cloud для генерации новой популяции. Думаю, что следует отказаться от ограничения в 100PR, а выдавать в первую очередь те агенты, PR которых больше PR самого слабого локального ядра (+или удалённого ядра, если такие подключены). Если таковых нет, то нагрузку следует как-то балансировать по времени. Например, если предположить, что все проходы проходят на одном  и том же ядре с одинаковой скоростью (в жизни, конечно не так, но многие эксперты с некоторыми допущениями, можно назвать стабильными по времени тестирования, независимо от параметров). Если PR локального ядра 150, а PR ядра в клауд - 100, тогда локальному агенту нужно дать задач в 1,5 раза больше нежели агенту в клауд. Или же, при меньшем PR не выдавать агентам в клауд задачи пачками, а по одной штуке, но более широкому кругу агентов. В этом случае, простои будут минимальны. В общем, хотелось бы увидеть продвижения в этом вопросе

 

За последние 12 часов, сеть подвисала ещё три раза :(

(И в  журналах по генетике встречаются агенты с PR < 100)

 
Кстати, ктонить на ssd пробовал агентов расшаривать? Учитывая как у меня винт хрустеть начинает на 8 агентах, даже без задач, что-то есть подозрение, что ресурс ssd быстро заканчивается. И при тестировании достаточно легкого советника, скорость вычисления, в скорость винтчестера упираться начинает. Скок там терабайт прокачивается в кеше вопрос хороший)
 
sion:
Кстати, ктонить на ssd пробовал агентов расшаривать? Учитывая как у меня винт хрустеть начинает на 8 агентах, даже без задач, что-то есть подозрение, что ресурс ssd быстро заканчивается. И при тестировании достаточно легкого советника, скорость вычисления, в скорость винтчестера упираться начинает. Скок там терабайт прокачивается в кеше вопрос хороший)

Есть такая буква в алфавите (я про ssd), но конкретных тестов не делал: т.к. сервер с таким девайсом находится на другом конце города. Но, ИМХО, в любой системе есть дисковый кэш, который сглаживает частые обращения к диску.

 
Интересно, кто столько ресурсов под это облако расшарил, износ системы с потреблением электричества, явно больше чем 2-3 цента в день. Несколько раз пытался предоставлять ресурсы, но уж больно гиблое дело, если меньше 10Гб на винте(при 9 Гб оперативы), при некоторых загрузках генетикой, систему просто тупо вешает, даже если и не съест все свободное место(оперативы и т.д. вплоть до свопа), один фиг винт на полную пытается кеш прокачать, что приводит к диким тормозам.
 
что не напишу вопрос так сразу исчезает.
Файлы:
Picture_61.png  585 kb
 

Решил пооптимизировать простенький гридер (таймер 30 сек, контроль нового m1 бара) на всех тиках по двум парам. Мои 4 ядра i5 (PR=160-170) и 8 ядер i7 (PR=170-180) выдали время оптмизации в р-не 90 (!) часов.

Потом оказалось, что проходы на i5 тестятся раза в 2 медленнее (хотя, как я несколько раз уже писал, ранее всё было на оборот - i5 + winxp64 был быстрее i7 + win7x64). Сначала скосил на память - её на i7 больше.

 А потом случайно глянул в диспетчер задач и увидел, что агенты имеют наинизший приоритет  (Low). Причём, на обеих машинах. И если на win7 мне удалось поднять приоритет до Normal, то winxp64bit почему-то не разрешает. За полдня с новыми приоритетами на i7 время тестирования сократилось (вродебы :)) на несколько часов.

 Такие "тормоза" вроде как два последних билда наблюдаются (а может мне это только кажется).

А приоритет Low - это слишком жестоко - если оборудование минимум 12 часов в сутки может дать агентам максимальный приоритет.

В общем, думал, что приоритет как-то автоматом от загрузки ресурсов меняется, но похоже, что сам он не меняется :( 

1...232425262728293031323334353637...44
Новый комментарий
Причина обращения: