Скачать MetaTrader 5
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Опубликовал программу в Маркете? Опубликуй ее и в блоге - виджет поможет!
Кирилл
53
Кирилл 2015.10.04 12:08  

Vlad143:

контроль неубывания времени при корректировках системного таймера на сервере или на компьютере с терминалом (игнорирование тиков, пришедших после сдвига времени до достижения отметки времени, имевшейся до этого сдвига).

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

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

Ihor Herasko
8640
Ihor Herasko 2015.10.04 19:19  
Scriptong:

ОК. Попробую на выходных. По результатам здесь и отпишусь. Только будут фигурировать названия Брокер №1 и Брокер№2, без упоминания названий.

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

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

Ihor Herasko
8640
Ihor Herasko 2015.10.04 19:28  
Kir_7:

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

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

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

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

Кирилл
53
Кирилл 2015.10.04 20:22  

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

Vladimir
292
Vladimir 2015.10.04 22:11  
Kir_7:
 

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

Системный таймер за неделю может уйти вперед или назад на сто и больше секунд. Это нехорошо по ряду причин, одну можно назвать сразу, это плохо для рассмотрения споров. Время нужно стараться держать поближе к астрономическому. По словам Рената Фаткуллина, с 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 сек, затем он "запаздывающий". При использовании клиентом запаздывающих тиков для сделок компания, как обычно, вправе сделку отменить. Естественно, не обязана. Встречал аналогичные ограничения в условиях конкурсов.

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

getch
1754
getch 2015.10.05 05:21  
Scriptong:

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

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

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

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

 

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

Кирилл
53
Кирилл 2015.10.05 07:16  
getch:

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

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

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

 

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

Кирилл
53
Кирилл 2015.10.06 07:21  
getch:

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

 

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

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

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

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

/ /1234
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий