EventChartCustom => indicator is too slow - страница 4

Новый комментарий
 

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

EventChartCustom => indicator is too slow

fxsaber, 2019.12.06 10:51

Если три тика с разными полями, но с совпадающим time_msc, то без индикатора-шпиона нет ни единого способа добраться до второго тика.

В такой ситуации в Тестере на чужом символе даже с индикатором-шпионом никогда не получится послать маркет-ордер на втором тике.

 
Slava:
Самый быстрый способ получать тики с чужих инструментов - в бесконечном цикле опрашивать эти инструменты SymbolInfoTick, не забыв при этом Sleep(1) в конце цикла

Оверхед просто чудовищный в тестере!

SymbolInfoTick и проверка изменения цены занимают в сотни раз больше времени, чем код боевого советника.

Миллисекундный таймер — заметно быстрее, но все равно значительно уступает варианту со шпионами.

Или я что-то делаю не так, или вы давно не тестировали мульти-символьных советников.


Постараюсь сделать простой код для воспроизведения, когда найду время.

 
Andrey Khatimlianskii:

Да, простая проверка

if ( GetTickCount64()-lparam > 16 ) return;

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

...но не спасла от "indicator is too slow".

Насколько я заметил, появление ошибки коррелирует с запуском тестера/оптимизатора. То есть, элементарно не хватает ресурсов.

 
Andrey Khatimlianskii:

...но не спасла от "indicator is too slow".


после 14-15 часов МСК у меня на индикаторе шпионе так было, это у меня было на core-i7 первого поколения, при смене на 3 поколение такая запись стала сильно реже, на райзене вообще исчезла

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

уже не помню с какого года поднимался вопрос про нормальную мультивалютность 

да и для себя не пойдет, как начинается движуха на рынке в 14-15 часов по мск - график встает, время скачками идет в обзоре рынка, сейчас может поменялось что-то на слабых ядрах, может еще пинг мой в терминале ~140 так обрабатывал пакеты

 

Вот статистика за 9 часов работы на 5 инструментах:

Windows 8.1 (build 9600) x64, IE 11, UAC, Intel Core i5-3570  @ 3.40GHz, Memory: 6979 / 16346 Mb, Disk: 341 / 499 Gb, GMT+2

[USDCHF]: 22784 of 22833 (99.8 %) ticks were processed (0.14 ms delay in average), 49 (0.2 %) ticks were skipped (103.4 ms delay in average)
[EURUSD]: 22944 of 22974 (99.9 %) ticks were processed (0.16 ms delay in average), 30 (0.1 %) ticks were skipped (115.6 ms delay in average)
[USDCAD]: 15331 of 15347 (99.9 %) ticks were processed (0.13 ms delay in average), 16 (0.1 %) ticks were skipped (104.6 ms delay in average)
[EURCHF]: 22516 of 22571 (99.8 %) ticks were processed (0.13 ms delay in average), 55 (0.2 %) ticks were skipped (127.8 ms delay in average)
[EURAUD]: 66842 of 66924 (99.9 %) ticks were processed (0.13 ms delay in average), 82 (0.1 %) ticks were skipped (117.8 ms delay in average)
[GBPUSD]: 41393 of 41393 (100.0 %) ticks were processed (0.00 ms delay in average)
Total trade requests time: 4.280 sec

Советник стоял на GBPUSD, поэтому для него работал родной OnTick.

Ошибок "indicator is too slow" не было.


А вот на ВПС от MQ и процент пропущенных тиков и средняя задержка сильно выше (чуть позже выложу статистику).
И ошибок "indicator is too slow" достаточно много.

Не понятна природа переполнения очереди, ведь советник обрабатывает накопившиеся события моментально (просто return-ится).
Кто-то еще ее обрабатывает?

 

Вот еще статистика с моего компа за несколько часов работы сегодня днем:

[USDCHF]: 33997 of 34161 (99.5 %) ticks were processed (0.81 ms delay in average), 164 (0.5 %) ticks were skipped (122.2 ms delay in average)
[EURUSD]: 36564 of 36717 (99.6 %) ticks were processed (0.82 ms delay in average), 153 (0.4 %) ticks were skipped (137.9 ms delay in average)
[USDCAD]: 19689 of 19783 (99.5 %) ticks were processed (0.74 ms delay in average), 94 (0.5 %) ticks were skipped (157.2 ms delay in average)
[EURCHF]: 43912 of 44105 (99.6 %) ticks were processed (0.74 ms delay in average), 193 (0.4 %) ticks were skipped (142.3 ms delay in average)
[EURAUD]: 76699 of 76965 (99.7 %) ticks were processed (0.73 ms delay in average), 266 (0.3 %) ticks were skipped (165.2 ms delay in average)
[GBPUSD]: 63984 of 63984 (100.0 %) ticks were processed (0.00 ms delay in average)
Total trade requests time: 3.826 sec


А вот аналогичная — c VPS от MQ:

Windows Server 2016 (build 14393) on Hyper-V x64, IE 11, RDP, Intel Xeon  E5-2670 v2 @ 2.50GHz, Memory: 15391 / 32767 Mb, Disk: 46 / 95 Gb, GMT+1
[USDCHF]: 49172 of 50475 (97.4 %) ticks were processed (0.56 ms delay in average), 1303 (2.6 %) ticks were skipped (5395.3 ms delay in average)
[USDCAD]: 49993 of 51550 (97.0 %) ticks were processed (0.48 ms delay in average), 1557 (3.0 %) ticks were skipped (5128.2 ms delay in average)
[EURCHF]: 83668 of 85528 (97.8 %) ticks were processed (0.58 ms delay in average), 1860 (2.2 %) ticks were skipped (4209.8 ms delay in average)
[EURAUD]: 129404 of 131855 (98.1 %) ticks were processed (0.48 ms delay in average), 2451 (1.9 %) ticks were skipped (5018.8 ms delay in average)
[GBPUSD]: 116467 of 118815 (98.0 %) ticks were processed (0.52 ms delay in average), 2348 (2.0 %) ticks were skipped (5286.1 ms delay in average)
[EURUSD]: 57653 of 57653 (100.0 %) ticks were processed (0.00 ms delay in average)

2% тиков пропускается, в журнале куча ошибок "indicator is too slow". Закономерностей между торговыми операциями и появлением ошибок нет.

@Slava, чарт_ивенты как-то связаны с графической подсистемой? Или с виртуализацией?

 
Andrey Khatimlianskii:

Вот еще статистика с моего компа за несколько часов работы сегодня днем:


А вот аналогичная — c VPS от MQ:

2% тиков пропускается, в журнале куча ошибок "indicator is too slow". Закономерностей между торговыми операциями и появлением ошибок нет.

@Slava, чарт_ивенты как-то связаны с графической подсистемой? Или с виртуализацией?

Чартэвенты связаны с системной очередью сообщений.

На наших хостингах вообще никакой отрисовки нет.

Пиковые нагрузки на cpu могут тормозить выборку сообщений из виндовой очереди.

 
Slava:

Чартэвенты связаны с системной очередью сообщений.

На наших хостингах вообще никакой отрисовки нет.

Пиковые нагрузки на cpu могут тормозить выборку сообщений из виндовой очереди.

Звучит, как приговор индикаторам-шпионам.

Что у нас еще для обмена данными есть, чтобы и в 4 и в 5, и в тестере и онлайн работало? Ресурсы? Буду тестировать.

 
Slava:

Будет потеря на постановке события таймера и на вызове OnTimer.

В бесконечном цикле со Sleep(1) таких потерь нет

С этим не экспериментировали? Написать простой воспроизводимый тест на скорость? Или это только мне интересно, и все равно ничего не будет меняться?

 
Andrey Khatimlianskii:

Вот еще статистика с моего компа за несколько часов работы сегодня днем:

Как стата собиралась?

123456
Новый комментарий
Причина обращения: