nuevo mql4 que proporciona milisegundos en los timestamps.... - página 3

Nuevo comentario
 

Todo,

La cuestión aquí es obtener la marca de tiempo del tick, y no el momento en que el tick llega a la terminal utilizando GetTickCount() (es decir, cuando se llama a la función start() ), como se sugiere.

MarketInfo(Symbol(), MODE_TIME) devuelve la marca de tiempo del tick tal y como se envía desde el servidor del broker en el feed de datos.

Saludos

VS

 
AnkaSoftware:

Todo,

La cuestión aquí es obtener la marca de tiempo del tick, y no el momento en que el tick llega a la terminal utilizando GetTickCount() (es decir, cuando se llama a la función start() ), como se sugiere.

MarketInfo(Symbol(), MODE_TIME) devuelve la marca de tiempo del tick tal y como se envía desde el servidor del broker en el feed de datos.

Lamentablemente, esto sólo tendrá una precisión de 1 segundo.
 
ubzen:

1) GetTickCount(), debería funcionar en vivo. No tiene sentido en datos históricos.

2) Incluso mt5_data no se guarda en milisegundos. Sin embargo, no_problema en vivo.

3) No veo a dónde quieres llegar con eso. Si es el mismo tiempo en milisegundos entonces tener milisegundos no ayudaría. Si son tiempos diferentes en milisegundos entonces GetTickCount() podría ayudar. Ayuda en el sentido de que su código procesa el tick actual en menos de un milisegundo. Qué tan importante es todo depende de lo que usted está tratando de lograr ... supongo.


Gracias a todos por sus respuestas. Hubo un indicador que se publicó en la base de código, Rogue Tick Detector. Pero aún no está aprobado. Por el momento, puede encontrarlo aquí.

La idea básica es que hay veces en las que el tick0 actual llegará con una marca de tiempo posterior al tick-1 anterior. Pero el precio ya no sería accionable, pero el EA o el comerciante humano no sabría esto hasta después del hecho. Esto causaba que los eventos basados en el precio se activaran erróneamente. El detector de ticks falsos era capaz de marcar estos ticks falsos y evitar que el EA actuara sobre ellos (esperar al siguiente tick "bueno")

El método actual de captura de timestmps de los ticks, MarketInfo(Symbol(), MODE_TIME), no devuelve timestamps de milisegundos. Por eso he venido aquí preguntando si hay alternativas que estemos pasando por alto.

Los EAs que incluyen las funciones de detección de garrapatas pícaras todos se ejecutan en VPS en Nueva York con unidades SSD, Windows 2008, y son por lo general <2ms del servidor del corredor. No hay HFT o hyperscalping (el tiempo de retención promedio de las operaciones es de aproximadamente 1 hora).

Me lleva de nuevo a una de mis preguntas originales: ¿Cómo se supone que la plataforma mt4 (y mt5 ) distingue adecuadamente entre los ticks que llegan al "mismo tiempo"?

editar, gracias ankasoftware para aclarar.

 
4evermaat:


Me hace volver a una de mis preguntas originales: Entonces, ¿cómo se supone que la plataforma mt4 (y mt5) distingue adecuadamente entre los ticks que llegan al 'mismo tiempo'?

No puede... ¿su corredor realmente le envía múltiples ticks que suceden al mismo tiempo? o simplemente incrementan la cuenta por 2 y envían el último tick? ¿cómo podría saber si lo hicieran? ¿es usted consciente de que hay una gran diferencia en la cuenta de ticks entre los corredores?
 
RaptorUK:
No puede... ¿su Broker le envía realmente múltiples ticks que ocurren al mismo tiempo? o simplemente incrementan el recuento por 2 y envían el último tick? ¿cómo podría saber si lo hicieran? ¿es usted consciente de que hay una gran diferencia en el recuento de ticks entre los Brokers?


Sí, soy consciente de que los diferentes brokers tienen diferentes feeds y el conteo de ticks puede diferir mucho. Pero sucede que los ticks falsos se envían durante ciertos momentos, principalmente cuando las operaciones se cierran con ganancias. Afectaba a la activación de los cierres y las órdenes, así que encontramos una forma de detectarlos e ignorarlos lo mejor posible. Incluso sospeché de una manipulación intencionada del feed en algún momento por parte de algunos de los brokers.

Pero tal vez deberíamos tener una relación de recuento de garrapatas, donde contamos el total de garrapatas

Es muy posible que no afecte a mucha gente, pero pensé que el daño potencial era suficiente para justificar una investigación más profunda.

 
No hay ninguna función/proceso que haga exactamente lo que pides [que yo sepa] en este momento.
4evermaat:Pero tal vez deberíamos tener una relación de conteo de ticks, donde contamos el total de ticks

¿Qué tienes en mente? ¿Cómo sería esto diferente de mt4 Volumen? Una relación de qué dos números [ cuenta y ??? ].

Este tema se vuelve muy confuso muy rápido. Yo mismo no sé todo sobre los ticks, ni cómo metaQuotes lo procesa, ni por qué será muy crítico para alguien. Permítame resumir algunas de mis observaciones.

1) metaQuotes dice: quieres mili_segundos time_stamp, [ inmediatamente empiezan a pensar en tick_data ], ¿quién va a guardar este tick_data el broker? ¿quieres decir que decirte que hay 200 ticks en ese minuto no es suficiente para ti? ¿Realmente quieres que guardemos 200 entradas de datos porque OHLC+V no es suficiente?

2) trader number1 dice: No necesito que nadie guarde la información sólo quiero mili_segundos de marca de tiempo para determinar los datos antiguos.

3) trader number2 dice: No necesito que me guarden la información, sólo denme la posibilidad de importarla y obtendré mis propios datos.

4) trader number3 dice: No veo por qué es tan importante guardar y proporcionar los datos de los ticks. Vamos, los ordenadores tienen más potencia y memoria hoy en día, seguro que mi broker puede proporcionar los datos en algún sitio.

5) broker dice: hombre ya me cuesta bastante darte datos m1 de más de 3_meses qué te hace pensar que soy capaz o estoy dispuesto a proporcionar tantos datos cuando te conectas o para hacer pruebas.

6) trader number4: no lo necesitamos para las pruebas y sólo una pequeña porción para los datos sería suficiente en vivo, no me quejo de la insuficiencia de m1 ahora así que cuál es el problema.

7) metaQuotes: todavía no va, esto significa que tendremos que facilitar las funciones que devuelve milli_seconds y los indicadores y tal que distingue ticks ... ¿estás tratando de bloquear el terminal o algo así?

8) trader number5: quieres decir que el volumen no es market_depth sino un recuento del número de ticks dentro de un time_frame determinado :) . ¿Quieres decir que puedo perder ticks? ¿Quieres decir que los ticks pueden perderse o retrasarse en el ciberespacio? ¿Quiere decir que el número de ticks difiere entre los corredores? ¿Quieres decir que los datos que el broker almacena no son los mismos que los que yo he recibido? ¿Por qué tanto alboroto por el tick entonces?

9) xxxxxxxxxxxx dice: el tick es alto secreto, lo que se proporciona ciertamente es lo suficientemente bueno, yo ayudé a diseñar el generador de tick y tengo muy poco interés en proporcionar ese tipo de resolución. no va a suceder.... punto.

10) trader number6: hay limitaciones tecnológicas, a lo que se puede proporcionar, cómo funciona el conteo de ticks, lo que se puede recibir, etc..etc. Esto no es un problema de metaTrader, más bien todas las plataformas minoristas experimentan este problema. Busque un software institucional y prepárese para gastar mucho dinero.

Trader#3 a Trader#10: no estoy de acuerdo.

Ubzen dice: Ya no sé qué decir.

Ps> casi se me olvida trader#7: bien, guardaré mi propio tick que llega a mi terminal y programaré mis propios indicadores y demás para procesar estos datos... Así es como interpreté la pregunta y por eso recomendé el GetTickCount().

 
ubzen:

Ps> casi me olvido trader#7: bien, guardaré mi propio tick que llega a mi terminal y programaré mis propios indicadores y tal para procesar estos datos... Así es como interpreté la pregunta y por eso recomendé el GetTickCount().

Desgraciadamente eso sigue sin hacer frente a los ticks perdidos... en la práctica es imposible guardar tus propios ticks, no puedes cogerlos todos y como se te escaparán algunos, a menos que se registre este hecho los datos guardados serán incorrectos por lo que potencialmente será peor que inútil, será engañoso.
 
RaptorUK: Lamentablemente, esto no permite hacer frente a los ticks perdidos... en la práctica es imposible guardar tus propios ticks, no puedes obtenerlos todos y, dado que se te escaparán algunos, a menos que se registre este hecho, los datos guardados serán incorrectos, por lo que, peor que inútiles, serán engañosos.

Espero permanecer en el tema aquí :). Dicho esto, imaginar un corredor que envía timeStamps milisegundos con cada garrapata. Pero, a continuación, proceder a no guardar esta información en su_lado. Teniendo en cuenta toda la desconfianza sobre los brokers en general, este broker abriría_una avalancha de consultas. Pero esta vez la gente tiene pruebas en milisegundos, pero el corredor no tiene registros para contrarrestar. Así que en cierto sentido, pedir tick_data | milisegundos o lo que sea que lleva a los mismos argumentos es básicamente pedir al broker que guarde los tick_data y que la plataforma lo facilite.

En una segunda nota, considere la inversa back-tests que la mayoría de los ppl hacer. Donde se ejecuta una estrategia_live durante una semana y luego se procede a realizar un back_test sobre esa semana en_orden a verificar si se obtienen los mismos resultados. Esta persona tiene milisegundos time_stamps en vivo y retrasos y paquetes perdidos en vivo. Por supuesto, al igual que el cartel original, ignora los datos que faltan y/o descarta los ticks retrasados. Sin embargo, cuando realiza el back-test, todos los datos del broker con timestamps correctos están ahí. Obviamente, esto generará resultados diferentes a los que recibiste en vivo.

Así que dime, ¿fuiste engañado en vivo o estás siendo engañado durante el Back_Test?

Sin embargo, estoy de acuerdo con su declaración anterior. Imo, todo esto crea un conjunto de paradojas que me lleva a permanecer lejos de los procesos inter_minutos all_together. La plataforma tiene limitaciones, yo simplemente acepto y sigo adelante.

 
ubzen:
...

Sin embargo, estoy de acuerdo con su declaración anterior. Imo, todo esto crea un conjunto de paradojas que me lleva a mantenerme alejado de los procesos inter_minutos por completo. La plataforma tiene limitaciones, las acepto y sigo adelante.

;-)
 
angevoyageur:

Temporizadores, resolución de temporizadores y desarrollo de código eficiente

Resolución del temporizador de Windows : Megawatts desperdiciados

Interesantes enlaces gracias, que me llevaron a los Servicios de Tiempo de Resolución de Microsegundos para Windows. He realizado algunas pruebas basadas en la información de esas páginas.

Mis pruebas en un PC con Win 7 y en un VPS con Windows 2012 indican que GetTickCount() siempre tiene una resolución de 15,6 mseg (64 interrupciones por segundo) independientemente de la configuración del temporizador del sistema, mientras que la resolución al obtener el tiempo en milisegundos llamando a las funciones de kernel32.dll GetSystemTime() [o GetLocalTime()] o GetSystemTimeAsFileTime() se ve afectada por la configuración del temporizador del sistema, y puede dar hasta 0,5 mseg de resolución en ambas máquinas que he probado.

Resolución de GetTickCount()

Aquí está el código de un script para probar la resolución de 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;
    }
}

Esto siempre da 15 o 16 (es decir, 15,6) en ambas máquinas probadas, independientemente de los cambios en la resolución del temporizador del sistema que se mencionan a continuación para las otras pruebas.

Resolución de GetSystemTime()

Ahora las cosas empiezan a ponerse interesantes. Aquí está el código de un script para probar la resolución de 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;
    }
  }
}

Esto da una resolución de 15/16 mseg en un PC recién arrancado sin ningún otro software en ejecución, ¡pero 1 mseg si Chrome se está ejecutando en el PC! Como explica el segundo enlace de angevoyageur, Chrome establece el temporizador del sistema con una resolución de 1 mseg, al igual que otros programas.

Encontré dos pequeñas utilidades para configurar la resolución del temporizador del sistema, de modo que se puede obtener una resolución de 1 mseg (o incluso 0,5 mseg) de forma controlada en una máquina arrancada limpiamente:

Herramienta del temporizador del sistema de Windows: http://vvvv.org/contribution/windows-system-timer-tool

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

Yo prefiero el primero de los dos, Windows System Timer Tool. Con ella he podido obtener de forma fiable una resolución de 1 mseg a través de GetSystemTime(). GetLocalTime() también podría usarse de forma similar.

Por cierto, el código de la secuencia de comandos anterior es un ejemplo de cómo el nuevo código de MT4 puede ser mucho mejor gracias a los structs. En la antigua MT4 acceder a GetSystemTime() requería el uso de un array de enteros además de mucha manipulación de bits.

Resolución de GetSystemTimeAsFileTime()

Por último, he observado que los Servicios de Tiempo con Resolución de Microsegundos para Windows mencionan que GetSystemTimeAsFileTime() es una función más rápida para acceder a la hora del sistema, además de requerir una estructura más pequeña y sencilla. Esto último es ciertamente cierto para la nueva MT4 ya que el "struct" puede ser reducido a sólo un ulong.

Aquí está el código de un script para probar la resolución de 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;
    }
  }
}

Si se utiliza la Herramienta del Temporizador del Sistema de Windows para establecer una resolución del temporizador del sistema de 0.5secs ese pequeño script reporta una resolución de 5000 (o a veces 5001) unidades de 100 nsecs = 0.5 msecs.

El uso de GetSystemTimeAsFileTiime() es de hecho más simple y puede mostrar una resolución más fina.

Aquí hay algunas fotos de este en uso.

Después de un arranque limpio:

Después de un arranque limpio

Con Timer Tool utilizado para establecer la resolución del temporizador del sistema a 1 ms:

Con la Herramienta del Temporizador, se ajusta la resolución del temporizador del sistema a 1 ms

Y con Timer Tool utilizado para establecer la resolución del temporizador del sistema a 0,5 ms:

Con la Herramienta del Temporizador se ajusta la resolución del temporizador del sistema a 0,5 ms

Conclusión

La mejor función para obtener tiempos en milisegundos en MT4 es GetSystemTimeAsFileTiime() llamada como se muestra en el script de prueba anterior, con una utilidad como Windows System Timer Tool utilizada para establecer la resolución deseada del temporizador del sistema.

1234
Nuevo comentario