Бета-версия платформы MetaTrader 5 build 2055: Интеграция с Python и массовые улучшения в тестере стратегий - страница 23
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В дополнение к распределению задач:
Не редко бывает, что, например, из четырёх агентов три уже закончили, а у одного прогресс 85%. И он в одиночку заканчивает, а мог бы поделиться с тремя другими.
Фреймы по прежнему теряются - крайне разочарован, так-как ожидал улучшения в данном вопросе в деле, а не на словах.
В логах тестера есть статистика по принятым фреймам. Вы получаете меньше фреймов, чем ожидали?
Как Вы обрабатывете фреймы? Покажите код отсылки фреймов, а также код приёма. Покажите Ваши функции OnTesterInit, OnTesterPass и OnTesterDeinit
Хоть какие-то доказательства Ваших слов приведите.
В логах тестера есть статистика по принятым фреймам. Вы получаете меньше фреймов, чем ожидали?
Как Вы обрабатывете фреймы? Покажите код отсылки фреймов, а также код приёма. Покажите Ваши функции OnTesterInit, OnTesterPass и OnTesterDeinit
Хоть какие-то доказательства Ваших слов приведите.
В логах тестера или агентов эта статистика? Да я получаю меньше, чем должно было быть по факту - у меня проверка в коде логическая(не привожу). Приходится перезапускать оптимизацию.
Обработка полученных фреймов
Тестирование идет в режиме "Математические вычисления".
Советник могу целиком дать в личку, если нужно. Причина потери, как и раньше, я полагаю в том, что один проход генерирует больше одного фрейма.
Добавлено: Хочу уточнить, что компиляция происходила на билде 2007, а оптимизация уже на новом билде - может это критично?
В логах тестера. Вот пример
11:20:18.691 Tester optimization finished, total passes 1002 (successful 1001 passes) 11:20:18.701 Statistics optimization done in 0 minutes 25 seconds 11:20:18.701 Statistics shortest pass 0:00:01.857, longest pass 0:00:12.700, average pass 0:00:05.174 11:20:18.701 Statistics 3003 frames (163.70 Mb total, 57160 bytes per frame) received 11:20:18.701 Statistics local 2 tasks (0%), remote 0 tasks (0%), cloud 1000 tasks (99%) 11:20:18.701 MQL5 Cloud Europe 1 hour and 25 minutes of cloud time spent on successful calculation of 998 tasks, 999 cloud agents used 11:20:18.701 MQL5 Cloud USA 7.159 sec of cloud time spent on successful calculation of 1 tasks, 1 cloud agents used 11:20:18.724 Tester 1001 new records saved to cache file 'tester\cache\Moving_Average_Frame.EURSEK.H1.20190215.20190610.00.9A4BE19E38D8F14F7D6382B8309A8149.opt'
1001 проход. Каждый послал по 3 разных фрейма. Все 3003 фрейма пришли
Если советник посылает несколько фреймов, то эти фреймы должны помечаться разными идентификаторами. Так как фрейм с одним и тем же номером прохода и идентификатором считается дублем. Дубли, особенно в математике и в клауде - неизбежны, поэтому такая проверка.
В логах тестера. Вот пример
1001 проход. Каждый послал по 3 разных фрейма. Все 3003 фрейма пришли
Если советник посылает несколько фреймов, то эти фреймы должны помечаться разными идентификаторами. Так как фрейм с одним и тем же номером прохода и идентификатором считается дублем. Дубли, особенно в математике и в клауде - неизбежны, поэтому такая проверка.
Вот лог
В одном проходе, должно быть 1000 фреймов, получается недополучили 7878 фреймов (3315*1000-3307122).
И на предыдущей странице я показал бездействие агентов, что подтверждает и этот кусок лога, так как время прохода должно быть примерно одинаковым между самым быстрым и средним.
Советник могу целиком дать в личку, если нужно. Причина потери, как и раньше, я полагаю в том, что один проход генерирует больше одного фрейма.
Сначала попытаемся воспроизвести собственными силами.
Я неправильно сказал про дубли. Одна посылка с тысячей фреймов обрабатывается как есть, без анализа идентификатора. Следующая посылка с таким же номером прохода будет считаться дубликатной, вся.
Странно, что количество недосланных фреймов не кратно тысяче.
Сначала попытаемся воспроизвести собственными силами.
Я неправильно сказал про дубли. Одна посылка с тысячей фреймов обрабатывается как есть, без анализа идентификатора. Следующая посылка с таким же номером прохода будет считаться дубликатной, вся.
Странно, что количество недосланных фреймов не кратно тысяче.
Понял. Я лишь замечу, что мне пришлось в тот раз останавливать часть агентов по причине - неравномерной раздачи заданий (большая часть простаивала) и по приине, что не удавалось продолжить оптимизацию (по всей видимости был обрыв связи и дальше не получалось установить связь с агентом).
Сейчас закончится оптимизация, где я не буду вмешиваться. Отпишусь о результатах.Сейчас закончится оптимизация, где я не буду вмешиваться. Отпишусь о результатах.
Всё плохо.
Всё плохо.
Все Ваши агенты под вашим контролем?
Попробуйте проанализировать код ошибки после FrameAdd. Если есть ошибка, то организовать деление на 0, чтобы спровоцировать критическую ошибку. Чтобы узнать какой из агентов виноват.
Посылка фреймов производится раньше посылки результата в том же потоке. Если результат дошёл, то фрейм тем более дойдёт. Если только он был правильно сохранен функцией FrameAdd