Пропали ядра после обновления тестера. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Это каким образом при оптимизации одного советника задачи то разные? Разная область поиска решения, но данные то едины. Я говорю в первую очередь о локальных агентах, и это особенно актуально, когда передаваемые данные исчисляются сотнями мегабайт.
Мы с вами уже обсуждали как-то технические вопросы. Оказалось, что вы в них не разбираетесь вообще.
Поэтому оставьте кесарю - кесарево.
Мы с вами уже обсуждали как-то технические вопросы. Оказалось, что вы в них не разбираетесь вообще.
Поэтому оставьте кесарю - кесарево.
Тут вопросы не технические, а практические - мне как пользователю, накладно по сети гонять гигабайты трафика для инициализации моих агентов. К тому же, агенты рвут связь и приходиться их запускать последовательно - уже не первый год говорю об этой проблеме - реакция вялая.
Тут вопросы не технические, а практические - мне как пользователю, накладно по сети гонять гигабайты трафика для инициализации моих агентов. К тому же, агенты рвут связь и приходиться их запускать последовательно - уже не первый год говорю об этой проблеме - реакция вялая.
Редкий случай. Возможно, его даже не воспроизводили.
Дайте все данные (пример советника и используемых файлов), тогда будет шанс.
Редкий случай. Возможно, его даже не воспроизводили.
Дайте все данные (пример советника и используемых файлов), тогда будет шанс.
Год назад я, наверное, месяц занимался тем, что тестировал для MQ работу агентов, теряли фреймы, тогда и советник давал, с фреймами вопрос решили, а с передачей больших файлов только обещали.
Тут все просто воспроизводиться - создаете шаблон советника, файл прописываете, который надо передать агентам
и переменную для оптимизации.
Это особенно актуально для математических вычислений при машинном обучении, лично я передаю выборку для распараллеливания вычислений на всех ядрах. MQ заявляли, что клауд вообще будет использоваться для научных там целей, и вот фактически эта цель и стоит - работа с базой данных.
И, если агенты, которые в локальной сети можно заставить запуститься, поочередно включая их, то те, что за пределами и до которых надо доползти через интернет, уже проблематично - по нескольку часов запускаешь руками оптимизацию.
Просто затратные и неэффективные эксперты. Их везде много.
Мы ежедневно апгредим клауд сеть, меняя рейтинги и подстраиваясь под экспертов.
Теперь вместо чистого PR используется сложная формула, учитывающая:
Это позволило резко снизить задержки от того, что некоторые задачи попадали к откровенно тормозных агентам, которые задерживали все вычисления.
Сейчас распределением задач занимаются три клауд сервера в США, Германии и России, что позволило серьезно снизить задержки в сети и ускорить доставку данных. Некоторые эксперты требуют репликации сотен гигабайт, а особо отличившиеся более террабайта.
В клауде мы разрешаем использовать только реальные ядра.
Статистика показала что много задач в клауде фейлятся из-за недостатка ресурсов. Очень затратные эксперты пошли.
За последний месяц мы кардинально улучшили MQL5 Cloud Network в скорости и отзывчивости.
Когда перейдем на новый тестер, который будет использовать один процесс на все ядра вместо отдельных процессов для каждого ядра, мы резко понизим потребность в ресурсах за счет единых кешей и сможем гибко управлять нагрузкой на все ядра.
Вот тут более подробно описал планы: https://www.mql5.com/ru/forum/340770/page7#comment_16401357Будет ли включена работа агентов в виртуальных машинах на VMWare ESX?
Купил на организацию много серверов на Xeon'ах от 20 ядер памяти на всех от 128Gb до 1.5Tb, с райдами на SSD c пропускной способностью до 3Гб в сек, но когда пробовал на них запускать агенты, то они ни разу не получали заданий, как я понимаю из-за ограничения работы в виртуальных машинах. А использовать несколько десятков серверов без виртуальных машин в 2020 году считаю верхом кощунства и неэффективного использования ресурсов.
Я думаю много простаивающих серверов по всему миру можно было бы подключить к сети агентов, если бы был решен вопрос с виртуальными машинами.
Будет ли включена работа агентов в виртуальных машинах на VMWare ESX?
Да, мы некоторое время назад сняли запрет на использование виртуалок в клауде.
Попробуйте снова, пожалуйста.
Год назад я, наверное, месяц занимался тем, что тестировал для MQ работу агентов, теряли фреймы, тогда и советник давал, с фреймами вопрос решили, а с передачей больших файлов только обещали.
Тут все просто воспроизводиться - создаете шаблон советника, файл прописываете, который надо передать агентам
и переменную для оптимизации.
Это особенно актуально для математических вычислений при машинном обучении, лично я передаю выборку для распараллеливания вычислений на всех ядрах. MQ заявляли, что клауд вообще будет использоваться для научных там целей, и вот фактически эта цель и стоит - работа с базой данных.
И, если агенты, которые в локальной сети можно заставить запуститься, поочередно включая их, то те, что за пределами и до которых надо доползти через интернет, уже проблематично - по нескольку часов запускаешь руками оптимизацию.
Для локальных агентов передать гигабайты таких данных вообще не проблема, так как сетевой канал для них работает в режиме Fast Path. Гигабайты пролетают со свистом.
Для локальной сети переслать сотни мегабайт тоже не составляет особого труда.
Для клаудов отсылка эксперта с данными происходит однократно на клауд серверы, а потом репликации на агентов. Тут ждем агенты-микроклауды, они смогут эффективнее работать с даннными.
Еще важно знать, что везде используются хеши объектов (по ним проверяется неизменность) и повсеместное кеширование данных. То есть, эксперты массов кешируются в памяти клауд серверов и не агентах. Это позволяет избегать множества репликаций до тех пор, пока программы не перекомпилируются.
Для локальных агентов передать гигабайты таких данных вообще не проблема, так как сетевой канал для них работает в режиме Fast Path. Гигабайты пролетают со свистом.
Для локальной сети переслать сотни мегабайт тоже не составляет особого труда.
Для клаудов отсылка эксперта с данными происходит однократно на клауд серверы, а потом репликации на агентов. Тут ждем агенты-микроклауды, они смогут эффективнее работать с даннными.
Еще важно знать, что везде используются хеши объектов (по ним проверяется неизменность) и повсеместное кеширование данных. То есть, эксперты массов кешируются в памяти клауд серверов и не агентах. Это позволяет избегать множества репликаций до тех пор, пока программы не перекомпилируются.
Про локальные, что на компьютере и запущены с которого тестирование - это и так понятно - тут проблем нет.
Переслать сотни мегабайт - может быть, но когда у тебя 100 агентов, то это уже 10 гигабайт! И да, некоторые агенты на WiFi и тут скорость значительно меньше, но это реали для домашнего размещения мощностей.
Есть ещё вариант же, когда компьютеры с агентами находятся не в твоей локальной сети, а удаленно, и передача заданий происходит уже через провайдера интернет - и тут скорость ещё меньше, чем по домашнему WiFi и происходят чаще недокачки и обрывы.
Я не понимаю, почему нельзя передавать один пользовательский файл на удаленную машину и распределять между всеми агентами...
Вы просто не чувствуете эту проблему, поэтому такое восприятие, а для многих это повседневность.
Не ясно, почему происходит тайм аут у агентов при закачки файлов - это вообще не ясно - мои агенты - сколько хочу столько им и закачиваю данных для обработки.
Да, есть другое решение - иметь аналог папки files для агентов и функционал MQL работы с ней, некий вариант ArhivFiles - тогда бы я сам на каждую удаленную машину залил файлы нужные и агент просто к ним бы обращался, не выкачивая каждый раз гигабайты.
Когда работаешь над идеей, то постоянно происходит перекомпиляция, поэтому все эти типа кэши/хэши под откомпилированный советник бесполезны при активной разработке идеи и добавлении кода в советник.
Поэтому я и пишу - не понимаете технических вопросов реализации.
Глупости про мифический ручной перенос не нужно писать. Все должно работать только автоматически с автоматической зачисткой мусора. Файлы экспертов передаются однократно и эффективно кешируются на агентах. Повторные запуски тестирования не приводят к перезакачке программ, пока они не будут перекомпилированы.
Рассказывать про роботов в сотни мегабайт тоже не надо. Кстати, как ресурсы, так и связанные файлы сжимаются при передаче.
Сейчас агенты независимы и работают как отдельные процессы, что имело смысл 10 лет назад, когда их разрабатывали. Было мало ядер, в десятки раз меньше данных и не такие прожорливые эксперты. Это было ошибочное решение, хотя на тот момент идея преимуществ отказа от внутренних точек синхронизации в работе тестера победила.
Что собираемся делать - вместо независимых агентов делать микроклауды. Что и как делать мы отлично понимаем и поэтому пошагово реформируем систему.
Собственные фермы у трейдеров не выстрелили. Сейчас стало абсолютно ясно, что будущее за клаудными рассчетами - это дешево и эффективно.
Да, потратишь 5-10 долларов на массовое тестирование идеи, но никакого геморроя, экономно и быстро.
Если есть проблемы с тестированием или тормозами, описывайте их с максимальной детализацией и логами, пожалуйста.
За последние полгода мы серьезно улучшили агентов и исправили множество проблем.
Следующий большой шаг - это переход на микроклауды, где вместо агента на ядро будут использоваться агенты на N ядер в рамках NUMA нод. Для этого нам надо многое переписать.