новый mql4 предоставление миллисекунд в метках времени.... - страница 3

 

Все,

Вопрос заключается в том, чтобы получить временную метку тика, а не время, когда тик поступает в терминал с помощью GetTickCount() (т.е. когда вызывается функция start()), как было предложено.

MarketInfo(Symbol(), MODE_TIME) возвращает временную метку тика, отправленную с сервера брокера в потоке данных.

С уважением,

VS

 
AnkaSoftware:

Все,

Вопрос заключается в том, чтобы получить временную метку тика, а не время, когда тик поступает в терминал с помощью GetTickCount() (т.е. когда вызывается функция start()), как было предложено.

MarketInfo(Symbol(), MODE_TIME) возвращает временную метку тика, отправленную с сервера брокера в потоке данных.

К сожалению, это будет только с точностью до 1 секунды.
 
ubzen:

1) GetTickCount(), должен работать на живых данных. Бессмысленно на исторических данных.

2) Даже mt5_data не сохраняются в миллисекундах. Однако, no_problem Live.

3) Я не понимаю, к чему вы клоните. Если это одно и то же время в миллисекундах, то наличие миллисекунд не поможет. Если это разное время в миллисекундах, то GetTickCount() может помочь. Поможет в том смысле, что ваш код обрабатывает текущий тик в течение менее чем миллисекунды. Насколько это важно, зависит от того, чего вы пытаетесь достичь... я полагаю.


Спасибо всем за ответы. В кодовую базу был выложен индикатор Rogue Tick Detector. Но он еще не утвержден. Пока что вы можете найти его здесь.

Основная идея заключается в том, что бывают случаи, когда текущий тик tick0 приходит с более поздней временной меткой, чем предыдущий tick-1. Но цена больше не будет действовать, но советник или человек-трейдер не узнает об этом до тех пор, пока это не произойдет. Это приводило к ошибочному срабатыванию событий, основанных на цене. Rogue tick detector мог отмечать эти фальшивые тики и не позволять советнику действовать по ним (ждать следующего "хорошего" тика).

Текущий метод захвата временных меток тиков, MarketInfo(Symbol(), MODE_TIME), не возвращает миллисекундные временные метки. Поэтому я пришел сюда, чтобы узнать, есть ли альтернативы, которые мы упускаем из виду.

Советники, которые включают функции обнаружения несанкционированных тиков, все работают на VPS в Нью-Йорке с SSD дисками, windows 2008, и обычно находятся на расстоянии <2 мс от сервера брокера. Никакого HFT или гиперскальпирования (среднее время удержания сделок составляет около 1 часа).

Это возвращает меня к одному из моих первоначальных вопросов: Так как же платформа mt4 (и mt5) [сама] должна правильно различать тики, которые приходят в "одно и то же время"?

редактировать, спасибо ankasoftware за разъяснение.

 
4evermaat:


Это возвращает меня к одному из моих первоначальных вопросов: Как платформа mt4 (и mt5)[сама] должна правильно различать тики, которые приходят в "одно и то же время"?

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


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

Но, возможно, нам следует ввести коэффициент подсчета клещей, когда мы считаем общее количество клещей.

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

 
На данный момент, насколько мне известно, нет ни одной функции/процесса, который делает именно то, о чем вы спрашиваете.
4evermaat:Но, возможно, мы должны иметь коэффициент подсчета тиков, где мы считаем общее количество тиков

Что вы имеете в виду? Чем это будет отличаться от mt4 Volume? Отношение каких двух чисел [ посчитать и ??? ].

Эта тема становится очень запутанной очень быстро. Я и сам не все знаю ни о тиках, ни о том, как их обрабатывает metaQuotes, ни о том, почему для кого-то это будет очень критично. Позвольте мне подытожить некоторые из моих наблюдений.

1) metaQuotes говорит: вам нужна временная метка в миллисекундах, [ они сразу начинают думать о тиковых данных ], кто будет хранить эти тиковые данные - брокер? Вы хотите сказать, что вам недостаточно 200 тиков в течение этой минуты? Вы действительно хотите, чтобы мы сохранили 200 записей данных, потому что OHLC+V недостаточно хороши?

2) трейдер №1 говорит: Мне не нужно, чтобы кто-то сохранял информацию, мне просто нужна временная метка в миллисекундах для определения старых данных.

3) трейдер №2 говорит: Мне не нужно, чтобы вы сохраняли информацию, просто дайте мне возможность импортировать ее, и я получу свои собственные данные.

4) трейдер №3 говорит: Я не понимаю, почему это такая большая проблема - сохранять и предоставлять тиковые данные. Да ладно, в наше время у компьютеров больше мощности и памяти, наверняка мой брокер может где-то предоставить эти данные.

5) Брокер говорит: Мужик, мне достаточно сложно предоставить тебе данные по m1 за более чем 3_месяца, с чего ты взял, что я способен или готов предоставить столько данных, когда ты подключишься или для тестирования.

6) трейдер №4: нам не нужно это для тестирования, и просто небольшой части для данных было бы достаточно в реальном времени, я не жалуюсь на недостаточное количество m1 сейчас, так в чем проблема.

7) metaQuotes: все еще нет, это означает, что нам придется облегчить функции, которые возвращают миллисекунды, индикаторы и тому подобное, что различает тики... вы пытаетесь завалить терминал или что?

8) трейдер №5: вы имеете в виду, что Volume - это не market_depth, а подсчет количества тиков на данном таймфрейме :) . То есть я могу пропустить тик? То есть тики могут потеряться или задержаться в киберпространстве? Вы имеете в виду, что счетчик тиков различается у разных брокеров? То есть данные, которые хранит брокер, не совпадают с теми, что я получил бы? Тогда что за суета вокруг тиков?

9) xxxxxxxxxxxx говорит: тик - это совершенно секретно, то, что предоставляется, конечно, достаточно хорошо, я помогал разрабатывать генератор тиков и очень мало заинтересован в предоставлении такого разрешения. не случится.... точка.

10) трейдер №6: существуют технологические ограничения на то, что может быть предоставлено, как работает подсчет тиков, что может быть получено и т.д. и т.п. Это не проблема metaTrader, скорее все розничные платформы испытывают эту проблему. Смотрите в сторону институционального программного обеспечения и будьте готовы выложить большие деньги.

Трейдер#3 - Трейдер#10: Я не согласен.

Ubzen говорит: Я просто не знаю, что сказать больше.

Ps> чуть не забыл трейдер#7: хорошо, я сохраню свои собственные тики, которые приходят на мой терминал и запрограммирую свои собственные индикаторы и тому подобное для обработки этих данных... Именно так я интерпретировал вопрос и именно поэтому я рекомендовал GetTickCount().

 
ubzen:

Ps> чуть не забыл трейдер#7: хорошо, я сохраню свой собственный тик, который приходит на мой терминал и запрограммирую свои собственные индикаторы и тому подобное для обработки этих данных... Именно так я интерпретировал вопрос и именно поэтому я рекомендовал GetTickCount().

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

Я надеюсь оставаться в теме здесь :). С учетом сказанного, представьте себе брокера, который посылает миллисекундные timeStamps с каждым тиком. Но, затем продолжает не сохранять эту информацию на своей стороне. Учитывая все недоверие к брокерам в целом, этот брокер открыл бы натиск запросов. Но на этот раз у людей есть доказательства за миллисекунды, а у брокера нет записей, которыми можно было бы парировать. Так что в некотором смысле запрос на тик_данные | миллисекунды или что-то еще, что приводит к тем же аргументам, по сути, является просьбой к брокеру сохранить тик_данные, а к платформе - содействовать этому.

В качестве второго замечания, рассмотрим обратные тесты, которые делает большинство людей. Где вы запускаете стратегию_live примерно на неделю, а затем выполняете обратный тест по истечении этой недели, чтобы проверить, получите ли вы те же результаты. У этого человека есть миллисекундные метки времени, задержки и пропущенные пакеты в реальном времени. Конечно, как и в случае с оригинальным плакатом, вы игнорируете недостающие данные и/или отбрасываете задержанные тики. Однако, когда вы проводите обратное тестирование, все данные брокера с правильными временными метками находятся там. Это, очевидно, даст результаты, отличные от тех, что вы только что получили в реальном времени.

Так скажите мне, вас ввели в заблуждение в прямом эфире или вас вводят в заблуждение во время Back_Test?

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

 
ubzen:
...

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

;-)
 

Спасибо за интересные ссылки, которые привели меня к службам времени с микросекундным разрешением для Windows. Я провел несколько тестов, основанных на информации с этих страниц.

Мои тесты на ПК Win 7 и VPS Windows 2012 показали, что GetTickCount() всегда имеет разрешение 15,6 мс (64 прерывания в секунду) независимо от настроек системного таймера, тогда как разрешение при получении миллисекундного времени путем вызова функций kernel32.dll GetSystemTime() [или GetLocalTime()] или GetSystemTimeAsFileTime() зависит от настроек системного таймера и может давать разрешение до 0,5 мс на обеих протестированных машинах.

Разрешение GetTickCount()

Вот код скрипта для проверки разрешения GetTickCount():

// Script to test Millisecond Resolution via GetTickCount()

void OnStart() {
  uint startMsecsU = GetTickCount(), nowMsecsU;
  for (int j=0; j<1000000000; j++) {
    if ((nowMsecsU = GetTickCount()) > startMsecsU) {
      MessageBox(StringFormat("GetTickCount %u -> %u diff %u", startMsecsU, nowMsecsU, nowMsecsU - startMsecsU), "Test Millisecond Resolution via GetTickCount");
      return;
    }
}

Он всегда дает 15 или 16 (т.е. 15.6) на обеих протестированных машинах, независимо от изменений разрешения системного таймера, упомянутых ниже для других тестов.

Разрешение GetSystemTime()

Теперь все начинает становиться интересным. Вот код сценария для проверки разрешения GetSystemTime():

/* Script to test Millisecond Resolution via GetSystemTime()

Windows struct for a GetSystemTime() or GetLocalTime() call:
typedef struct _SYSTEMTIME {
  WORD wYear;
  WORD wMonth;
  WORD wDayOfWeek;
  WORD wHour;
  WORD wMinute;
  WORD wSecond;
  WORD wDay;
  WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME;
*/

// MT4 equivalent struct:
struct _SYSTEMTIME {
  ushort wYear;         // 2014 etc
  ushort wMonth;        // 1 - 12
  ushort wDayOfWeek;    // 0 - 6 with 0 = Sunday
  ushort wDay;          // 1 - 31
  ushort wHour;         // 0 - 23
  ushort wMinute;       // 0 - 59
  ushort wSecond;       // 0 - 59
  ushort wMilliseconds; // 0 - 999
};

#import "kernel32.dll"
void GetSystemTime(_SYSTEMTIME &time);
#import

void OnStart() {
  _SYSTEMTIME st;
  GetSystemTime(st);
  int startMsecs = st.wMilliseconds, nowMsecs;
  for (int j=0; j<1000000000; j++) {
    GetSystemTime(st);
    if (st.wMilliseconds != startMsecs) {
      nowMsecs = st.wMilliseconds;
      if (nowMsecs < startMsecs)
        nowMsecs += 1000; // wMilliseconds wrapped
      MessageBox(StringFormat("GetSystemTime msecs %d -> %d diff %d", startMsecs, nowMsecs, nowMsecs - startMsecs), "Test Millisecond Resolution via GetSystemTime");
      return;
    }
  }
}

Это дает разрешение 15/16 мс на свежезагруженном ПК без других запущенных программ, но 1 мс, если на ПК запущен Chrome! Как объясняет вторая ссылка angevoyageur, Chrome устанавливает системный таймер на разрешение 1 мс, как и некоторые другие программы.

Я нашел две небольшие утилиты для установки разрешения системного таймера, так что разрешение в 1 мс (или даже 0,5 мс) может быть получено контролируемым способом на чистой загруженной машине:

Инструмент системного таймера Windows: http://vvvv.org/contribution/windows-system-timer-tool

Timer-Resolution: http://www.lucashale.com/timer-resolution/

Я предпочитаю первый из этих двух вариантов, Windows System Timer Tool. С его помощью я могу надежно получить разрешение 1 мс через GetSystemTime(). Аналогично можно использовать GetLocalTime().

Кроме того, приведенный выше код скрипта является примером того, насколько лучше может быть новый код MT4 благодаря структурам. В старом MT4 доступ к GetSystemTime() требовал использования целочисленного массива плюс множество беспорядочных манипуляций с битами.

Разрешение GetSystemTimeAsFileTime()

Наконец, я отметил, что в Microsecond Resolution Time Services for Windows упоминалось, что GetSystemTimeAsFileTime() является более быстрой функцией для доступа к системному времени, а также требует меньшей и более простой структуры. Последнее, безусловно, верно для нового MT4, поскольку "структура" может быть уменьшена до простого ulong.

Вот код скрипта для проверки разрешения GetSystemTimeAsFileTiime():

// Script to test Millisecond Resolution via GetSystemTimeAsFileTime()

#import "kernel32.dll"
void GetSystemTimeAsFileTime(ulong &SystemTimeAsFileTime); // Returns the system time in 100 nsec units in a ulong
#import

void OnStart() {
  ulong startL, nowL;
  GetSystemTimeAsFileTime(startL);
  for (int j=0; j<1000000000; j++) {
    GetSystemTimeAsFileTime(nowL);
    if (nowL > startL) {
      int diff = int(nowL - startL);
      MessageBox(StringFormat("GetSystemTimeAsFileTime %llu -> %llu diff %d in 100 nsec units = %.1f msecs",
                 startL, nowL, diff, diff/10000.0), "Test Millisecond Resolution via GetSystemTimeAsFileTime");
      return;
    }
  }
}

При использовании Windows System Timer Tool для установки разрешения системного таймера в 0,5 секунды этот маленький скрипт сообщает о разрешении в 5000 (или иногда 5001) единиц 100 нсек = 0,5 мсек.

Использование GetSystemTimeAsFileTiime() действительно проще и может показать более тонкое разрешение.

Вот несколько фотографий этой функции в использовании.

После чистой загрузки:

После чистой загрузки

С помощью Timer Tool для установки разрешения системного таймера в 1 мс:

С помощью инструмента Таймер используется для установки разрешения системного таймера на 1 мс

И с Timer Tool, используемым для установки разрешения системного таймера на 0,5 мс:

С помощью инструмента Таймер используется для установки разрешения системного таймера на 0,5 мс

Заключение

Лучшей функцией для получения миллисекундных таймингов в MT4 является GetSystemTimeAsFileTiime(), вызываемая, как показано в тестовом скрипте выше, с утилитой, такой как Windows System Timer Tool, используемой для установки желаемого разрешения системного таймера.

Причина обращения: