Мы запускаем облачный сервис MQL5 Cloud Network! - страница 124
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я понимаю что оно ждёт. И все это понимют. Вопрос в том что это ожидание дальше не сдвигается. Расчёт останавливается полностью из-за того что некоторые удалённые агенты в облаке не возвращают результат. Поэтому я и задал вопрос когда это дело пофиксят? Неужели так сложно реализовать распределение "умерших" задач по другим агентам? С октября ведь уже запустили и всё никак не работает. Зато деньги у вас всегда чётко взимаются без проблем. А по сути услугу то мы не получаем в нужном объёме из-за недоработки.
Распределение умерших работает, но у него есть достаточно существенный доверительный интервал по таймауту.
В оценке мертвости есть серьезная проблема - как в рамках "каждый проход из-за разных настроек может иметь разное время выполнения" правильно оценивать таймаут? Если таймауты ставить буквально и исключительно точно (даже с учетом среднего времени), то оказывается, что половина агентов становятся незаслуженно отвергнуты, причем их работу приходится оплачивать. В этом случае стоимость оптимизации легко может получиться в 2 раза дороже.
Мы проводили много тестов, подбирая разные условия и пришли к выводу, что практически всегда временно затормозившие агенты возвращают результаты и что нужно использовать достаточно большой доверенный интервал по таймауту. Этот интервал заведомо больше человеческого уровня терпения, что выливается в ожидание. Причем это видно только в генетике с короткими циклами генерации популяций, а при полном переборе тормознутые агенты практически незаметны.
Важно учитывать, что у новых тестов на новом брокере с новыми символами включается механизм распространения и кеширования исторических данных как на клауд, так и с клауда на выбранных агентов. То есть, агенты должны выкачать/синхронизировать достаточно большую историю перед началом реальной работы. Это приводит к серьезных задержкам на старте, если у агентов нет этой истории (в последующем используются закешированные данные). Причем за задержки на синхронизации агентов нельзя штрафовать и время, потраченное на синхронизацию, не оплачивается.
Для уменьшения влияния задержек в генетике мы применяем несколько специальных методов:
Откуда тогда берутся записи следующего вида:
Там как минимум второе ядро этого агента отработало и получило статистику.
Там как минимум второе ядро этого агента отработало и получило статистику.
Второе ядро агента??? Не вносите сумятицу в терминологию ;)
Тогда зайдём с другой стороны. Ради получения PR-оценки на мобильный i5-непомнюсколько установлено 4 агента (как и предлагалось), через час тестер стратегий удалён (чужая машина). В списке агентов в профиле появилось 3 агента (а не 4, как должно быть по смыслу Вашего ответа), 2 из которых выполнили по 1 заданию. Что скажете?
PS. Предлагаю вернуть PR агенту, т.е. чтобы в менеджере агентов показывать PR всегда, а не смотреть через сайт в ожидании выполненного задания. А ещё лучше текущий, максимальный, и средний PR по агенту. Кажется, такая информация пригодилась бы для диспетчеризации задач.
Второе ядро агента??? Не вносите сумятицу в терминологию ;)
Тогда зайдём с другой стороны. Ради получения PR-оценки на мобильный i5-непомнюсколько установлено 4 агента (как и предлагалось), через час тестер стратегий удалён (чужая машина). В списке агентов в профиле появилось 3 агента (а не 4, как должно быть по смыслу Вашего ответа), 2 из которых выполнили по 1 заданию. Что скажете?
PS. Предлагаю вернуть PR агенту, т.е. чтобы в менеджере агентов показывать PR всегда, а не смотреть через сайт в ожидании выполненного задания. А ещё лучше текущий, максимальный, и средний PR по агенту. Кажется, такая информация пригодилась бы для диспетчеризации задач.
Распределение умерших работает, но у него есть достаточно существенный доверительный интервал по таймауту.
В оценке мертвости есть серьезная проблема - как в рамках "каждый проход из-за разных настроек может иметь разное время выполнения" правильно оценивать таймаут? Если таймауты ставить буквально и исключительно точно (даже с учетом среднего времени), то оказывается, что половина агентов становятся незаслуженно отвергнуты, причем их работу приходится оплачивать. В этом случае стоимость оптимизации легко может получиться в 2 раза дороже.
Мы проводили много тестов, подбирая разные условия и пришли к выводу, что практически всегда временно затормозившие агенты возвращают результаты и что нужно использовать достаточно большой доверенный интервал по таймауту. Этот интервал заведомо больше человеческого уровня терпения, что выливается в ожидание. Причем это видно только в генетике с короткими циклами генерации популяций, а при полном переборе тормознутые агенты практически незаметны.
Важно учитывать, что у новых тестов на новом брокере с новыми символами включается механизм распространения и кеширования исторических данных как на клауд, так и с клауда на выбранных агентов. То есть, агенты должны выкачать/синхронизировать достаточно большую историю перед началом реальной работы. Это приводит к серьезных задержкам на старте, если у агентов нет этой истории (в последующем используются закешированные данные). Причем за задержки на синхронизации агентов нельзя штрафовать и время, потраченное на синхронизацию, не оплачивается.
Для уменьшения влияния задержек в генетике мы применяем несколько специальных методов:
Вам нужно написать в Сервисдеск и предоставить все необходимые данные для воспроизведения. Это позволит найти и выявить ошибки.
Вы что-то перепутали, это вам нужно. Человек 5 дней пытается объяснить о проблеме, а MQ ему рассказывают, как работает сеть (информация, безусловно, очень ценная).
"lordlev, не могли бы вы написать об этой проблеме в сервисдеск, приложив все необходимые данные для воспроизведения? Это помогло бы нам выявить нашу ошибку"
Хотя, чего это я? Извините, опять глаз резануло...
Вы что-то перепутали, это вам нужно. Человек 5 дней пытается объяснить о проблеме, а MQ ему рассказывают, как работает сеть (информация, безусловно, очень ценная).
"lordlev, не могли бы вы написать об этой проблеме в сервисдеск, приложив все необходимые данные для воспроизведения? Это помогло бы нам выявить нашу ошибку"
Хотя, чего это я? Извините, опять глаз резануло...
Объяснения со стороны lordev были большей частью словесные, я старался ответить на основе данных объяснений.
В результате дошли до штатного "нужно больше детальной информации".
Ошибки конечно же исправляем.
В результате дошли до штатного "нужно больше детальной информации".
Дело не в Cloud.
Как я ранее писал - при включении агентов на лету - не воспроизводится. А вот при добавлении удалённого агента во время отпимизации (через контексное меню по пункту Remote->Добавить) (и включении его в список активных) - воспроизводится с первого раза - т. е., в ближайшее или следующее поколение все агенты переходят в состояние finished, которое вечно. Если не понятно, могу видео выложить.
+ от советника не зависит.
Дело не в Cloud.
Как я ранее писал - при включении агентов на лету - не воспроизводится. А вот при добавлении удалённого агента во время отпимизации (через контексное меню по пункту Remote->Добавить) (и включении его в список активных) - воспроизводится с первого раза - т. е., в ближайшее или следующее поколение все агенты переходят в состояние finished, которое вечно. Если не понятно, могу видео выложить.
+ от советника не зависит.
Спасибо за интересную особенность с добавление на лету удаленного агента.
Будем проверять - тикет я уже выставил.