Советник, записывающий тиковую историю. Как сохранить все тики ? - страница 4

Насчет скрипта для сбора тиков - очень оригинальное решение! Правда!

А вот насчет корректировок времени... Что это вообще такое, как часто случается и чем чревато для истории тиков игнорирования этого явления, не объясните ?

До конца осуществить задуманное пока не удалось, т. к. для начала нужно было создать график такого типа (High - максимальный Bid, Low - минимальный Ask). С этой задачей справляется версия 1.02 моего сборщика тиков (заявка на публикацию в Code Base подана). 

Следующим шагом как раз будет разработка скрипта, который будет рассчитывать сумму колен ZigZag'a с заданными значениями параметров. 

Да, если задача стоит в сборе данных именно об изменении цены, то скрипт является выходом. А вот если стоит задача словить все тики, приходящие в терминал, то здесь он будет вынужден пропускать данные, т. к. одинаковые тики (когда прошлый Bid равен новому Bid, а прошлый Ask равен новому Ask) воспримет как отсутствие новой котировки. Индикатор решает эту проблему.

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

Я провел небольшое исследование. За неделю записи тиков при помощи эксперта  тиков с повторными ценами Ask и Bid у меня получилось 0,137% от общего числа. За неделю записи тиков при помощи индикатора  тиков с повторными ценами Ask и Bid получилось 0,122%. Пара EUR/USD. Недели разные, то есть сравнивать эти проценты между собой нельзя. Только рассматривать их для общей информации. Да, такие тики есть, но их очень немного. Вопрос. А какая практическая польза может быть от записи таких тиков ? Да и тики ли это вообще ? Ведь по логике вещей, цены (Bid и Ask) равны ценам Bid и Ask текущего тика до прихода следующего, с новыми ценами. Если в этот промежуток времени открыть или закрыть ордер, то он будет исполнен по цене текущего тика (в идеале). Тик с ценами, идентичными ценам предыдущего тика, никакой дополнительной информации не несет, кроме той, что подтверждает, что к моменту его прихода цены не изменились. И какая от этого польза ?

Системный таймер за неделю может уйти вперед или назад на сто и больше секунд. Это нехорошо по ряду причин, одну можно назвать сразу, это плохо для рассмотрения споров. Время нужно стараться держать поближе к астрономическому. По словам Рената Фаткуллина, с 2006 года в составе сервера MT4 поставляются штатные средства синхронизации системного таймера с астрономическим временем, однако заставить всех администраторов серверов ими пользоваться не удалось по сей день. Поэтому, если собрать на одном экране левые верхние углы окон терминалов разных компаний с видимым верхом окна обзора рынка и сделать скриншот, то показываемое там в верхней строке последнее время сервера будет запросто отличаться на несколько секунд. В начале 2014 я это сделал для 31 компании и в течение суток сделал 31 скриншот. От среднего времени отличались на 20 секунд в одну сторону три: FXStart, RBC Forex, ProfiForex (по слухам, у них один хозяин). Еще три отличались на 9 секунд, штук 5 на 3 секунды, остальные 1-2 секунды, что для меня уже говорит о работающем механизме синхронизации времени сервера с астрономическим.

Если таймер сервера убегает вперед, то каждая корректировка дает сдвиг времени назад. Если протокол RFC 867 с секундной погрешностью, то время может скакнуть вниз до двух секунд. В случае, когда тиковые истории используются для анализа с учетом времени, это нонсенс. Приходится игнорировать приходящие тики до тех пор, пока время снова не начнет расти. В случае протокола RFC 868, где корректировки осуществляются на миллисекунды, приходится делать то же самое. На биржах, где последовательность сделок и поступление заявок должны отслеживаться без пропусков, их не игнорируют, а корректируют время по "плавному" алгоритму, без уходов вниз. Подробнее, по сведениям за март 2010 (Дмитрий Глотиков, Фондовая биржа РТС, http://forum.rts.micex.ru/viewtopic.asp?t=15432), на бирже так: GPS приемник (с погрешность до 50 наносекунд) стоит на собственном NTP сервере, ядро торговой системы работает в режиме постоянной синхронизации времени с "плавным подводом" часов. По той же ссылке можно видеть, зачем нужна такая дорогая синхронизация в случае биржи. На розничном форекс, как правило, никто о ней не задумывается. Любителей тиковых историй не так много.

Обнаружив в 2008, что на серверное время надеяться не приходится, я стал проставлять отметки времени по приходу тиков на мой компьютер, точнее, по моменту появления обновленных курсов в выходном историческом файле. Пришлось поднять точность синхронизации таймера на компьютере, вышло до 20 мс.

Scriptong:

"Да, если задача стоит в сборе данных именно об изменении цены, то скрипт является выходом. А вот если стоит задача словить все тики, приходящие в терминал, то здесь он будет вынужден пропускать данные, т. к. одинаковые тики (когда прошлый Bid равен новому Bid, а прошлый Ask равен новому Ask) воспримет как отсутствие новой котировки. Индикатор решает эту проблему."

Мне нужны именно данные об изменении цены. На случай, когда важно и повторение тиков, можно выгонять в историю и прежние тики по признаку изменения последнего времени прихода тика MarketInfo(Symb, MODE_TIME). Сам не проверял, но это так, если верить https://www.mql5.com/ru/forum/123413:

"TimeCurrent() берет время любого из инструментов который последний тик дал, а MarketInfo(Symbol(), MODE_TIME) - берет время последней котировки именно по конкретному инструменту"

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

Kir_7:

"Ведь по логике вещей, цены (Bid и Ask) равны ценам Bid и Ask текущего тика до прихода следующего, с новыми ценами. Если в этот промежуток времени открыть или закрыть ордер, то он будет исполнен по цене текущего тика (в идеале). Тик с ценами, идентичными ценам предыдущего тика, никакой дополнительной информации не несет, кроме той, что подтверждает, что к моменту его прихода цены не изменились. И какая от этого польза ?"

Вижу один вариант пользы. Real Trade Group, Ltd. в договорных документах установил, что тик действует 30 сек, затем он "запаздывающий". При использовании клиентом запаздывающих тиков для сделок компания, как обычно, вправе сделку отменить. Естественно, не обязана. Встречал аналогичные ограничения в условиях конкурсов.

Есть, вероятно, еще какая-то польза, только мне непонятная. Встречал у одной компании, что она не обязана отсылать на терминал курсы бид и аск, если они не изменились. Зачем они это обговаривают, не знаю.

Свой вариант выкладывал на форуме (здесь видео). На некоторых брокерах есть Ask-символы, поэтому тики собирать не требуется.

Аналогично, в ветке по ЗЗ делился индикатором. Можете сравнить результат.

 

Кстати, из-за отсутствия гарантии доставки всех тиков, помимо упомянутых коллегами выше проверок, делаю еще одну: если HighBid или LowAsk поменялись на баре, при этом тик был пропущен MQL4++, то пишу еще тик, соответствующий этим новым вершинкам.То же самое касается цен открытия и прочее.

И в какой же промежуток времени (между какими тиками) вы вставляете эти пропущенные тики ? Ведь минимальный таймфрейм, на котором Вы можете отловить изменения High и Low, равен 1 минуте, а тики приходят в среднем 1 в секунду. Иногда бывает до 11 тиков в секунду (выборку делал небольшую, чисто для информации, для себя).

Раз на текущем тике мы видим, что OHL-данные текущего бара поменялись, по сравнению с предыдущим тиком. И при этом текущий тик за эти изменения не отвечал, значит был пропущенный тик (между предыдущим и текущим), который OHL-данные и изменил. Соответственно, вклиниваем этот тик перед текущим. Время ему берем любое, в промежутке между предыдущим и текущим. Вроде, очевидно же.

 

Специально не проверял, но почти уверен, что формирование текущего бара не отстает от тиков. Тем более, не пропускает их. 

Теперь я понял ход Ваших рассуждений. Ваше допущение, "что формирование текущего бара не отстает от тиков" по-моему не очень надежно, хотя и логично. В любом случае, этот способ позволит восстановить пропущенный тик только в очень частном случае, когда цена Bid пропущенного тика больше цены High или меньше цены Low еще не достроенного бара на M1. А во-вторых, цену Ask пропущенного тика в этом случае восстановить не удастся, так как бар строится по ценам Bid. А в тиковой истории самое ценное это как раз спред, для чего нужны обе цены - Bid и Ask.

Абсолютно восстановить не получится - точно. Но в пропущенном тике вообще смысла чуть больше, чем ноль (длительность не позволяла исполнить - индикатив, короче). Поэтому если уж хочется его хоть и частично (только Bid точно) восстановить, то Ask можно считать неизменным с предыдущего тика.

У нормальных брокеров бары строятся и по аск-ценам. Индикаторы, использующие такие бары, выкладывал на форуме. Там уж точно никаких пропусков крайних значений.