Определение количества пропущенных баров при разрыве связи

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

Может у кто-то уже делал определение количества пропущенных баров при разрыве связи через функцию IsConnected, т.е. нужно, чтобы при разрыве связи запоминалось время последнего пришедшего бара, а после восстановления связи - определялось количество пропушенных баров, в соответствии с разницей времени которое было запомнено, и временем последнего бара, который пришел после восстановления связи. После этого запускался цикл пересчета этих баров в индикаторе. Но важно еще то, чтобы IsConnected не блокировал работу при переходе в автономный режим.

Если кто делал такое - поделитесь, пожалуйста.

 

Определение кол-ва пропущенных баров не делал за ненадобностью. Делал скрипт, который просто проводил аудит моментов перехода в оффлайн и обратно в онлайн, т.е. только сохранял время.

Функция IsConnected() - не совсем надежна (была, по крайней мере, когда некие версии терминала не переподключались из-за этого после потери связи), поэтому я проверял онлайн путем подсчета таймаута от времени прихода последнего тика (известного времени сервера). Терминал сам знает, какое количество баров каждого индикатора уже посчитано, и если общее количество баров увеличится, то в коде индикаторы вы элементарно получите Bars - IndicatorCounted() количество новых баров. Не замечали никогда, что правильные индикаторы после коннекта достраиваются на только что полученных барах? NB. Судя по проблемам с быстродействием (из ветки про оптимизацию), может быть какие-то индикаторы пересчитываются на все бары или скажем на несколько тысяч баров истории на каждый вызов? Это надо пофиксить.

 

Индикаторы по-любому будут пересчитаны, если есть пропущенные бары - используемая конструкция с IndicatorCounted() это предполагает. Правда, будут пересчитаны ВСЕ бары в истории. Можно сделать конструкцию, где пересчитываются только пропущенные бары, но здесь можно нарваться на различные баги типа докачки истории за пределами пропущенного периода. Короче, не имеет смысла. ИМХО, разумеется.

А так... сделать можно. Разрывы связи вообще больная тема. Дело в том, что докачка происходит не ДО появления первого тика после возобновления связи и даже не обязательно после него, а тогда, когда это будет удобно серверу котировок. Обычно после нескольких тиков. Для страховки некоторые подходы подразумевают задержку включения советника на 5...10 мин после возобновления связи.

Посморите здесь 'Разрывы связи'.

 
marketeer писал(а) >>

Определение кол-ва пропущенных баров не делал за ненадобностью. Делал скрипт, который просто проводил аудит моментов перехода в оффлайн и обратно в онлайн, т.е. только сохранял время.

Функция IsConnected() - не совсем надежна (была, по крайней мере, когда некие версии терминала не переподключались из-за этого после потери связи), поэтому я проверял онлайн путем подсчета таймаута от времени прихода последнего тика (известного времени сервера). Терминал сам знает, какое количество баров каждого индикатора уже посчитано, и если общее количество баров увеличится, то в коде индикаторы вы элементарно получите Bars - IndicatorCounted() количество новых баров. Не замечали никогда, что правильные индикаторы после коннекта достраиваются на только что полученных барах? NB. Судя по проблемам с быстродействием (из ветки про оптимизацию), может быть какие-то индикаторы пересчитываются на все бары или скажем на несколько тысяч баров истории на каждый вызов? Это надо пофиксить.

Я не хочу пользоваться функцией IndicatorCounted, при докачке истории она делает прерывания в работе индикатора по нескольку раз, и после прерываний пересчитывает всю историю заново, вообще, насколько я понимаю, эта функция не для учета пропущенных баров, а для оптимизации вычислений.

Что касается моей ТС, о которой я пишу в соседней ветке, в ней нет пересчета истории.Все вычисления, в том числе и используемых индикаторов, которые вмонтированы внутрь ТС, происходят только на нулевом баре, а далее заносятся в сдвиговый регистр (который имеет только 1000 разрядов необходимых для работы системы), который на каждом новом баре смещает всю информацию на разряд, поэтому, при разрыве связи я не могу восстановить данные, у меня нет работы с историей в ТС, и я хотела при разрыве связи фиксировать количество пропущенных баров, а после восстановления связи задать цикл пересчета в ТС только по этим барам.

190

 
Angela >>:

1) Я не хочу пользоваться функцией IndicatorCounted,...

2) я хотела при разрыве связи фиксировать количество пропущенных баров, а после восстановления связи задать цикл пересчета в ТС только по этим барам.

1) Правильно, что не хотите. Судя по описанию, эта функция в советниках не работает, только в индикаторах.

2) Зачем эти титанические усилия, просто начните заполнять свои массивы сначала, будто советник только что стартанул.

 

Что нибудь вроде

int barshift = iBarShift(NULL, PERIOD_M1, lasttime, true);
datetime lasttime = TimeCurrent();

if (barshift > 1)
   ...
 
gip писал(а) >>

Что нибудь вроде

Хорошо, попробую.

 
OneDepo писал(а) >>

1) Правильно, что не хотите. Судя по описанию, эта функция в советниках не работает, только в индикаторах.

2) Зачем эти титанические усилия, просто начните заполнять свои массивы сначала, будто советник только что стартанул.

На то, чтобы массив набрал минимально необходимое количество данных для работы ТС (для моей ТС это 30 баров), нужно много времени, при работе на М5 это 2.5 часа, все это время торговли не будет.

Вообщем-то, я пытаюсь решить эту проблему только из эстетических побуждений, не приятно смотреть на графики, где из-за разрыва связи рисунки на истории сдвинутся. На работу самой ТС ни разрывы связи, ни дыры в истории не влияют из-за того, что ее работа не привязана к истории котировок, внутри функции int start() нет никаких циклов, кроме одного, внутри которого реверсивный массив сдвигающий данные на 1 разряд по приходу нового бара.

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