Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не совпадают результаты проходов при оптимизации и одиночном проходе (сервис-деск - #329165 + советник там-же)
Не совпадают результаты проходов при оптимизации и одиночном проходе (сервис-деск - #329165 + советник там-же)
Билд 619? Тоже такая проблема начала проявляться. Но не всегда. Бывает даже, что результаты те же, то есть, оптимизацию новую не проводил, но при тестировании почему-то результаты уже другие выводятся. Например, итоговая прибыль на графике отличается от той, что в списке. Через некоторое время всё восстанавливается. До билда 619 такого не замечал ни разу.
билд ещё 607 (до нового FIBO пока не обновился). Возможно, проблема в мультивалютносте и таймере (OnTick() не используется), но не уверен.
Что-то намутили в последнем билде с тестером стратегий. Вдруг (не совсем "вдруг", а после обновления к 619 билду) советник практически перестал тестироваться (тот-же, что и в заявке #329165) - память начала потребляться немеренно (режим "Все тики" за 5 лет):
Последний столбец - "VM size". Как видите, 4 ядра у меня + 4 "удалённых" локальных агента (всегда нормально работало).
При этом система начинает очень жутко тормозить (угу, 4ГБ ОЗУ + 16Гб отдал под PageFile) и скорость оптимизации стремится к бесконечности. Как видно, процессорное время, практически не занимается.
При этом ошибки в журнале:
Это видимо из-за нехватки памяти.
Нажимаю "стоп" - память сразу не освобождается. Минут через 5 исчезли локальные агенты, ещё минуты через две, освободилась память удалённых:
Только непонятно, почему у одного агента всё-равно осталось больше 100Мб висеть (то, что его занял Cloud - не верю, ибо процесорное время не используется).
Что-ж, отключаю "удалённых" локальных агентов. Ничего не меняется (тормоза системы и ошибки).
Ну, думаю, грешным делом, ошибки у меня в советнике. Поэтому запускаю на тестирование стандартный ExpertMACD, EURUSD, h12 c 2007.09.01 по 2012.03.26.
И... таже картина - тормоза, бешенное потребление памяти (показатели почти такие же как и на первой картинке) + "cannot initialize expert".
В обеих случаях, некоторым проходам всё-же удаётся совершиться.
Лог прикреплён.
Весьма интересны строчки:
и т. д. с USDNOK - в моём советнике в коде был прошит один символ SGDJPY - зачем качать USDNOK (USDJPY успешно закачан по логам), вместо USDSGD?
Если что, сервер - FIBOGroup-MT5-сервер.
P. S. В предыдущих билдах не наблюдал таких проблем.
P. P. S. Кому не лень - проверьте, пожалуйста, у себя оптимизацию стандартного ExpertMACD на промежутке последних лет 5 по всем тикам.
Что-то намутили в последнем билде с тестером стратегий. Вдруг (не совсем "вдруг", а после обновления к 619 билду) советник практически перестал тестироваться (тот-же, что и в заявке #329165) - память начала потребляться немеренно (режим "Все тики" за 5 лет):
Последний столбец - "VM size". Как видите, 4 ядра у меня + 4 "удалённых" локальных агента (всегда нормально работало).При этом система начинает очень жутко тормозить (угу, 4ГБ ОЗУ + 16Гб отдал под PageFile) и скорость оптимизации стремится к бесконечности. Как видно, процессорное время, практически не занимается.
Не рекомендуется запускать агентов больше, чем есть ядер. От чрезмерного количества агентов скорость падает нелинейно, а затраты ресурсов растут. Тем более, когда всего 4 Gb памяти, а агенты съедают по гигабайту и больше.
Не инсталлируйте удаленных агентов на том же компьютере, где ведете свою основную работу с терминалом.
При этом ошибки в журнале:
Это видимо из-за нехватки памяти.
Нажимаю "стоп" - память сразу не освобождается. Минут через 5 исчезли локальные агенты, ещё минуты через две, освободилась память удалённых:
Да, память (кеши) освобождаются примерно через 5 минут. Они специально держатся на случай следующего запуска, чтобы не терять время на разогрев чаще всего тех же данных, что были использованы на прошлом запуске.
В последнем билде мы изменили работу с кешами, что привело к их увеличению ради ускорения повторных проходов.
Только непонятно, почему у одного агента всё-равно осталось больше 100Мб висеть (то, что его занял Cloud - не верю, ибо процесорное время не используется).
Что-ж, отключаю "удалённых" локальных агентов. Ничего не меняется (тормоза системы и ошибки).
Ну, думаю, грешным делом, ошибки у меня в советнике. Поэтому запускаю на тестирование стандартный ExpertMACD, EURUSD, h12 c 2007.09.01 по 2012.03.26.
Вы перекомпилировали эксперта после апгрейда на последний билд?
В Вашем случае проблема в в тормозах из-за постоянного свопинга и недостатка памяти. Совет: отключите лишних удаленных агентов.
Не рекомендуется запускать агентов больше, чем есть ядер. От чрезмерного количества агентов скорость падает нелинейно, а затраты ресурсов растут. Тем более, когда всего 4 Gb памяти, а агенты съедают по гигабайту и больше.
Не инсталлируйте удаленных агентов на том же компьютере, где ведете свою основную работу с терминалом.
Вы перекомпилировали эксперта после апгрейда на последний билд?
В Вашем случае проблема в в тормозах из-за постоянного свопинга и недостатка памяти.
Совет: отключите лишних удаленных агентов.
Отключил, запустил на оптимизацию ExpertMACD и:
А теперь отключил все агенты (в том числе локальные) кроме одного:
и что теперь? 4ГБ мало на одного агента? (хотя Mem Usage - 350МБ, VM Size = 1,24Гб). А что делать тем, у кого даже 4ГБ нет?
Может всё-таки проверите? Этапы воспроизведения - в предыдущем посте
Можете посмотреть в статистике по Cloud - что 4, что 8 агентов - PR всё-равно в р-не 150-190 (кроме одного/двух, которые видимо выпадают на ядро браузера) Отключил удалённые агенты... Эксперты перекомпилированы. Даже штатного ExpertMACD перекомпилировал.
Отключил, запустил на оптимизацию ExpertMACD и:
А теперь отключил все агенты (в том числе локальные) кроме одного:
и что теперь? 4ГБ мало на одного агента? (хотя Mem Usage - 350МБ, VM Size = 1,24Гб).
Может всё-таки проверите? Этапы воспроизведения - в предыдущем посте
Достаточно было посмотреть в лог эксперта, чтобы увидеть ошибки:
Выберите правильный период времени и правильные настройки. Если используете дефолтные пределы, то можете сгенерировать множество неправильных параметров.
Достаточно было посмотреть в лог эксперта, чтобы увидеть ошибки:
Выберите правильный период времени и правильные настройки. Если используете дефолтные пределы, то можете сгенерировать множество неправильных параметров.
Да, действительно, проблема в дефолтных параметрах оказалась. Изменил - всё нормально тестируется. Вернулся к своему советнику - вроде тоже пока "полёт нормальный".
Итого, если раньше прощалось наличие двух агентов на ядро, то теперь уж точно нет.
Итого2. Был неправ, извините за отнятое время (но сервис-деск - #329165 пока ещё не разобрался)
Разберёмся.
Что-то всё затянулось. А тем временем я выяснил в чём дело.
1) Во фремя рефакторинга кода, у меня потерялось явное присвоение значения переменной и иногда (совсем рандомно) получались случайные результаты для объёма открываемой позиции. Исправив эту ошибку, увидел, что результат не поменялся - результаты тестов не совпадают с оптимизацией. Путём различного логирования и танцев с бубном удалось выяснилось, что проблема достаточно давняя:
2) Перед началом чемпионата-2011 я сообщал, что тестер проводит сделки в выходные дни. Renat обещал проверить. Но проблема осталась до сих пор. Совершенно случайно, я выбрал начало промежутка тестирования 2007.09.01, который является выходным днём. Так вот - оптимизатор в этот день сделку не проводит, а тестер проводит. Вернее, в оптимизаторе не доходит до OrderSend в выходной, а в тестере доходит. Исходя из логики моего эксперта удалось выяснить, что если старт промежутка оптимизации припадает на выходной, то при первом срабатывании таймера, ACCOUNT_EQUITY = 0!!! А в тестере ACCOUNT_EQUITY = ACCOUNT_BALANCE (то что и задаём в начальном депозите). Если начало промежутка оптимизации припадает на рабочий день, то поведение оптимизатора и тестера идентично.
Итого, у Вас два бага:
1) Тестер позволяет открыть сделку в выходной, чего не должно быть (и не надо говорить, что это моя ошибка - свои ошибки я поправлю, а баг тестера уже больше полгода висит);
2) При первом срабатывании таймера, если начало периода припадает на выходной, ACCOUNT_EQUITY = 0, а в тестере ACCOUNT_EQUITY = ACCOUNT_BALANCE. Нужно привести к одному виду (лучше, конечно, к ACCOUNT_EQUITY = ACCOUNT_BALANCE c исправлением первой ошибки).
В сервис-деске по заявке #329165 прикреплю эксперта для тестов.