"Семеро одного ждут!" или как равномерно загрузить агентов локальной вычислительной сети во время оптимизации - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Для ускорения оптимизации 10 компьютеров были объединены в PVN (Private Virtual Neywork). Вместе с сервером всего получилось 125 агентов. Но во время оптимизации получается такая картина. 124 агента быстро заканчивают свои задания и ждут, пока один последний агент завершит свое задание,а это может занять по времени 5 и более минут. И цикл снова повторяется, опять 99% агентов быстро справляются со своими заданиями, но не могут приступить к следующим, пока 1% (это 1 или 2 агента) не закончат свою работу, а это опять несколько минут. Работая в таком режиме, тестер стратегий большую часть времени простаивает, и вместо того, чтобы закончить оптимизацию за 2-3 часа, на нее уходит 12 часов и больше.
В связи с вышесказанным вопросы.
Тестер стратегий принимает какие-либо меры для равномерной загрузки агентов во время оптимизации, так чтобы все агенты примерно в одно и то же время получали задания и примерно в одно и то же время завершали задания? Чтобы не было такого перекоса, когда "семеро одного ждут".
Что можно сделать, чтобы помочь тестеру избежать таких перекосов?
У Вас что задания всегда кратны 125+1, как так может получатся, если производительность одинаковая? Быть может Ваш советник делает какие либо окончательные вычисления после оптимизации - формирует тысячи отчетов, или ещё какие действия выполняет?
У Вас что задания всегда кратны 125+1, как так может получатся, если производительность одинаковая? Быть может Ваш советник делает какие либо окончательные вычисления после оптимизации - формирует тысячи отчетов, или ещё какие действия выполняет?
Это генетический алгоритм формирует пачки по 128 или 256 наборов параметров.
Это генетический алгоритм формирует пачки по 128 или 256 наборов параметров.
Тогда понятно, просто не пользуюсь генетикой.
Когда по какой то причине выпадает большая нагрузка на одного агента, а другие закончили уже работу, то я просто отключаю того агента и включаю снова - таким образом нагрузка перераспределяется заново между всеми агентами.
Тогда понятно, просто не пользуюсь генетикой.
Когда по какой то причине выпадает большая нагрузка на одного агента, а другие закончили уже работу, то я просто отключаю того агента и включаю снова - таким образом нагрузка перераспределяется заново между всеми агентами.
При полном переборе такая проблема может возникать только в самом конце оптимизации. С генетикой так постоянно, на каждой пачке заданий.
При полном переборе такая проблема может возникать только в самом конце оптимизации. С генетикой так постоянно, на каждой пачке заданий.
Тогда, наверное, разработчиком стоит учитывать количество агентов и бросать им одинаковое число пачек - я б просто добавил каждому агенту, тогда пользователь бы не жаловался :)
Тогда, наверное, разработчиком стоит учитывать количество агентов и бросать им одинаковое число пачек - я б просто добавил каждому агенту, тогда пользователь бы не жаловался :)
Так и делается. Но некоторые проходы идут дольше, чем другие, даже на одинаковых агентах.
Так и делается. Но некоторые проходы идут дольше, чем другие, даже на одинаковых агентах.
Ну, тот уже индивидуальность советника, её предсказать сложно. В общем, если всё так, как Вы говорите, то это не проблема, а издержки производства.
Для ускорения оптимизации 10 компьютеров были объединены в PVN (Private Virtual Neywork). Вместе с сервером всего получилось 125 агентов. Но во время оптимизации получается такая картина. 124 агента быстро заканчивают свои задания и ждут, пока один последний агент завершит свое задание,а это может занять по времени 5 и более минут. И цикл снова повторяется, опять 99% агентов быстро справляются со своими заданиями, но не могут приступить к следующим, пока 1% (это 1 или 2 агента) не закончат свою работу, а это опять несколько минут. Работая в таком режиме, тестер стратегий большую часть времени простаивает, и вместо того, чтобы закончить оптимизацию за 2-3 часа, на нее уходит 12 часов и больше.
В связи с вышесказанным вопросы.
Тестер стратегий принимает какие-либо меры для равномерной загрузки агентов во время оптимизации, так чтобы все агенты примерно в одно и то же время получали задания и примерно в одно и то же время завершали задания? Чтобы не было такого перекоса, когда "семеро одного ждут".
Что можно сделать, чтобы помочь тестеру избежать таких перекосов?
Если у Вас есть хотя бы один локальный агент, то в конце расчёта генетического поколения, если какая-то особь считается дольше других, то набор параметров, соответствующий этой особи, отдаётся на выполнение локальному агенту. И тут уже кто быстрее выполнит.
Но это защита от явно медленных и маломощных агентов. Если все Ваши агенты равноценны, то тут замедление происходит от набора параметров. Чисто дольше рассчитывает - тут вряд ли что-то поделаешь
Да, все агенты равноценны, 9 компов i7 имеют по 12 ядер, включая локальный комп, и один комп в сети i9 имеет 20 ядер. Но что-то я не заметил, что задание, которое считается дольше других, снимается и передается на выполнение локальному агенту. Особь, которая считается дольше других, может возникнуть на любом агенте: локальном или сетевом, и возникнув, будет досчитываться на нем до конца.
Значит, я правильно понимаю, что устранить проблему перекоса, когда в одной пачке заданий встречаются, условно говоря, быстрые и медленные задания?Нет, советник не делает "каких-либо дополнительных вычислений после оптимизации", не формирует никаких отчетов, или другие действия.