Ошибки, баги, вопросы - страница 213

 
Olegts:

как видно из рисунка, работают только три ядра, сталкивался не раз с ситуацией, когда в процессе тестирования количество ядер участвующих в работе постепенно падало до нуля, после чего вступали в работу все разом, т.е. есть простой в работе, почему освободившиеся ядра не начинают работу сразу?

 

Для того, чтобы начать обсчитывать следующее поколение, надо сначала обработать текущее поколение. Все прогоны текущего поколения должны быть завершены для того, чтобы выбрать лучшие и провести между лучшими генетические операции. Только после этого можно запускать в работу следующее поколение.

Когда осталось досчитать несколько недостающих результатов до завершения обработки текущего поколения, освободившиеся агенты тестирования не работают.

 
stringo:


Спасибо
 
Virty:

какое максимальное время можно ставить в EventSetTimer(  )?

INT_MAX?  По моему нет. Не хочу исследовать самостоятельно, а в хелпе нет.


Время тут можно подставить любое, но в тестере время будет браться по модулю 50 дней. Примерно 4 220 000 секунд.

Чёто-както качество MQL5 демотивирует.

 
Virty:

Время тут можно подставить любое, но в тестере время будет браться по модулю 50 дней. Примерно 4 220 000 секунд.

Чёто-както качество MQL5 демотивирует.

 

Можно задать максимум 2 147 483 секунды (что соответствует 35 791 минуте, 596 часам или 24 дням). В тестере иначе обрабатывается таймер.

Встречный вопрос. Зачем выставлять таймер на 24 дня? 

 
stringo:

Можно задать максимум 2 147 483 секунды (что соответствует 35 791 минуте, 596 часам или 24 дням). В тестере иначе обрабатывается таймер.

Встречный вопрос. Зачем выставлять таймер на 24 дня? 

Хочется, чтобы позиция закрывалась после открытия через время от 1 секунды до 10 лет в зависимости там от чего то. 

Пробовал это сделать так

 request.type_time=ORDER_TIME_SPECIFIED;      // Ордер будет действовать до даты истечения
 request.expiration=1; //или TimeCurrent()+time; (int time=1;)

не работает с секундами.

Обошёл эту проблему  через EventSetTimer(  ). Тоже ограничение на 24 дня. И главное я такой пакости от таймера не ожидал. Предупреждать же надо. Ну ладно.

Кстати время в таймере реальное календарное или только время торгов? Другими словами сразу после выходных на таймере сколько натикает? 

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 

Снова зафиксирован случай частичной потери связи терминала с сервером. Build 360. Котировки не поступают, но сведения о времени и объёме сделок обновляются. На индикаторе состояния подключения вращающийся круг с серыми секторами. В журнале сообщения:

2010.11.29 18:03:03 Trades '630031' : deal #2107036 buy 0.10 GBPUSD at 1.55387 done (based on order #2157432)
2010.11.29 18:00:02 Trades '630031' : deal #2106895 buy 0.10 GBPUSD at 1.55341 done (based on order #2157265)
2010.11.29 17:07:49 Network '630031': authorized on MetaQuotes-Demo
2010.11.29 17:07:47 Network '630031': connection to MetaQuotes-Demo lost
2010.11.29 16:10:47 Network '630031': trading has been disabled - investor mode
2010.11.29 16:10:47 Network '630031': terminal synchronized with MetaQuotes Software Corp.
2010.11.29 16:10:47 Network '630031': authorized on MetaQuotes-Demo
2010.11.29 16:10:45 Network '630031': connection to MetaQuotes-Demo lost

Обратите внимание на отсутствие сообщения "terminal synchronized with MetaQuotes Software Corp." после 17:07:49, в то же время сведения о новых сделках поступили.


 

 

Rosh:
Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.

 


Держите.

 

Тестовая система (какая уж была!): Windows XP SP3, Pentium 4, 3GHz, память 1,25Gb

Все прогоны выполнялись на данных Alpari-Demo, GPBUSD M1, период 04.10.2010-05.11.2010 (1521376 ticks, 34194 bars) в режиме Обычный, Каждый тик, депозит 10000USD (кстати, где Вы взяли депозит 1000000USD? У меня список кончается на 100000), плечо 1:100. Был сооружен советник, который для упрощения конструкции использует особенность счёта Alpari-Demo - нулевую маржу. На каждый тик советник открывает ордер размером 0.1 лота в одну сторону, пока не достигнет заданного через параметр количества сделок, остальные тики пропускаются. Таким образом, влияние количества трейдов сведено к минимуму (на всех прогонах на тестовых данных получился 1 трейд). Попутно по окончании каждого прогона засекалось примерное время формирования отчёта в формате Open XML (пока не превысило порога терпения). Сделки, формируемые тестером в конце тестирования, в расчет не брались (по одной на прогон).

Итак:

Первая серия тестов от 10 до 100 сделок с шагом 10 особого интереса не представляет из-за малого времени теста. Время генерации тиков от 5359 до 6453.

Далее серия от 100 до 1000 сделок с шагом 100 (результат для 100 взят из предыдущей серии):

 
Сделки Время, ms Total time, ms
Приблизительное время формирования отчета xlsx, с Примечания
100 6359 6813
5 Менее 5 секунд
200 6172 6594
5
300 6875 7375
7
400 5734 6094
10
500 6109 6562

14

600 6281 6687
17
700 8016 8563
23
800 7281 7719
28
900 9047 9610
35
1000 8453 8812
44

 

В целом всё хорошо, но начинает проявляться проблема с формированием отчёта

 

 
Ashes:

Все прогоны выполнялись на данных Alpari-Demo, GPBUSD M1, период 04.10.2010-05.11.2010 (1521376 ticks, 34194 bars) в режиме Обычный, Каждый тик, депозит 10000USD (кстати, где Вы взяли депозит 1000000USD?
Это не проблема, нужная сумма может быть вбита руками.
 

Заключительная серия (на этом железе далее проверять слишком сурово по отношению ко мне;) от 1000 до 10000 c шагом 1000:

Здесь тормоза, о которых с сомнением отозвался Rosh  , проявляются во всей красе.

 
Сделки Время, ms Total time, ms
Приблизительное время формирования отчета xlsx, с Примечания
1000 8453 8812
44

2000 26750 27266
159

3000 60782 61141
355
**
4000 125469 171391
480 Более 480 секунд **
5000 414609 459281
Нет данных Формирование отчета для прогонов более 4000 сделок не выполнялось
6000 600610 601094
Нет данных

7000 648234 675576
Нет данных

**
8000 1082437 1082796
Нет данных

9000 1465203 1508359
Нет данных

10000 1988031 2012500
Нет данных

Перефразируя Rosh'а, как видно из построенной диаграммы, зависимость времени тестирования от количества СДЕЛОК НЕ строго линейная. Скорее,совсем не линейная.

Результат на 5000 и 6000, скорее всего, несколько завышен, но тенденция просматривается.

Напомню, результат получен на простейшем советнике, который практически не тратит времени на какой-либо анализ и не использует индикаторы, т.е., на рабочем советнике результаты были бы ещё печальнее.

Для сравнения:

Прогон этого теста с 10000 сделок на машине Windows 7, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) занял 472866 мс.

В свете вышесказанного есть некоторая вероятность того, что часть кандидатов на участие в чемпионате 2010 могла быть незаслуженно отсеяна из-за 15-минутного барьера и особенностей тестера (если было достаточно много сделок).

** - при проведении тестов несколько раз по завершении теста не отображался график символа с отображением сделок.

 

Interesting:
Это не проблема, нужная сумма может быть вбита руками.

 

Спасибо, не знал.