"Семеро одного ждут!" или как равномерно загрузить агентов локальной вычислительной сети во время оптимизации

 

Для ускорения оптимизации 10 компьютеров были объединены в PVN (Private Virtual Neywork). Вместе с сервером всего получилось 125 агентов. Но во время оптимизации получается такая картина. 124 агента быстро заканчивают свои задания и ждут, пока один последний агент завершит свое задание,а это может занять по времени 5 и более минут. И цикл снова повторяется, опять 99% агентов быстро справляются со своими заданиями, но не могут приступить к следующим, пока 1% (это 1 или 2 агента) не закончат свою работу, а это опять несколько минут. Работая в таком режиме, тестер стратегий большую часть времени простаивает, и вместо того, чтобы закончить оптимизацию за 2-3 часа, на нее уходит 12 часов и больше.

В связи с вышесказанным вопросы.
Тестер стратегий принимает какие-либо меры для равномерной загрузки агентов во время оптимизации, так чтобы все агенты примерно в одно и то же время получали задания и примерно в одно и то же время завершали задания? Чтобы не было такого перекоса, когда "семеро одного ждут".

Что можно сделать, чтобы помочь тестеру избежать таких перекосов?

 

Все задания разные и они никак не могут заканчиваться в одно и то же время.

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

 

Было учтено, что минимум 1 ядро нужно оставить для нужд системы? Антивирус случайно не каспер?

 
SEM: Было учтено, что минимум 1 ядро нужно оставить для нужд системы? Антивирус случайно не каспер?

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

 
Aleksandr Volotko: Все задания разные и они никак не могут заканчиваться в одно и то же время. Вы можете обратить внимание какие именно агенты дольше всего справляются со своим заданием, может их стоит исключить.

Действительно, все задания разные, но я говорю о том, что хотелось бы, чтобы все агенты примерно в одно и тоже время начинали и примерно в одно и тоже время заканчивали работу. Да, какое-то время тратилось на ожидание отстающих или отстающего агента, но чтобы это время занимало менее 5-10% от всего времени оптимизации. А сейчас получается, что накладные расходы на ожидание - это более 80% от всего времени оптимизации.

Вы предлагаете "обратить внимание какие именно агенты дольше всего справляются со своим заданием", чтобы "их исключить". Очевидно, Вы предполагаете, что это медленные агенты, но это не так, все агенты имеют примерно одинаковые характеристики i9, i7.

 
Eugene Myzrov:

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

Вы хотите невозможного. Понимаете, что все задания разные, но хотите, чтобы они выполнялись за одинаковое время. Так не бывает.

Eugene Myzrov:

Вы предлагаете "обратить внимание какие именно агенты дольше всего справляются со своим заданием", чтобы "их исключить". Очевидно, Вы предполагаете, что это медленные агенты, но это не так, все агенты имеют примерно одинаковые характеристики i5, i7.

Тут уж ничего не поделать. Раз уж индекс производительности у агентов примерно одинаков, то пользовать как есть. Другого не получится.

 
Eugene Myzrov:

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

Отключите два ядра. Teamviewer может полностью забирать ресурсы 1 ядра, получается, что для системы ничего не остается. Обратите внимание, что в большинстве случаев на серверах частота как правило не больше 2.5, а на рабочих станциях i5,i7 выше 3. По поводу производительности i5 и i7 - у i7 только 4 полноценных ядра, а не 8, фактически прирост производительности по сравнению с i5 примерно в 1.5 раза, а не в 2 (если считать ядра в диспетчере задач). 
 
Aleksandr Volotko: Вы хотите невозможного. Понимаете, что все задания разные, но хотите, чтобы они выполнялись за одинаковое время. Так не бывает. Тут уж ничего не поделать. Раз уж индекс производительности у агентов примерно одинаков, то пользовать как есть. Другого не получится.

Тут еще одна проблема наслаивается...

Предыдущая версия советника летает, в том смысле, что в разных режимах оптимизация проходит очень быстро. А оптимизация новой версии советника при некоторых значениях параметров зависает на несколько часов. Перешерстил весь код, ну нет там ничего такого, чтобы вычисления выросли в разы... Вот эту особенность я заметил, что работает 1 агент, а остальные 124 ждут, но следствие чего это, непонятно...

 

Я тоже постоянно сталкиваюсь с такой проблемой. У меня - существенно различные мощности компьютеров, работают новые и старые. И ситуация, когда "семеро одного ждут" - постоянно возникает.

Лично я борюсь с ней, отключая слабые компьютеры на время бектеста. А при форвард-тесте - включаю, там ожидания уже нет.

 
Eugene Myzrov:

Что можно сделать, чтобы помочь тестеру избежать таких перекосов?

Сделайте так, чтобы при любых параметрах советник открывал одинаковое кол-во сделок и тестировался одинаковое кол-во времени )

Или откажитесь от генетики, тогда агенты будут считать постоянно.

 

Вобще, надо попробовать помудрить с событием OnTesterPass и результатом INIT_AGENT_NOT_SUITABLE.

После получения данного кода возврата - агент не будет получать задания до конца оптимизации.  Вот, хорошо бы понять - до полного конца оптимизации ? Или только до текущего периода (бэк-оптимизации) ? Если только до конца текущего периода, то при бэк-оптимизации - можно возвращать это значение, и в результате агент не будет участвовать в генетическом бэк-тестировании, когда происходит ожидания полного поколения. А во-время форвард-тестирования - возвращать нормальный результат инициализации - после которого слабый агент будет работать.

Надо проверить это.

Вобще, интересно, может, разработчики сразу скажут ответ - агент, получивший результат инициализации INIT_AGENT_NOT_SUITABLE на бэк-тестировании - получит ли фрейм тестирования при начале форвард-теста ?

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