nouveau mql4 fournissant des millisecondes dans les timestamps.... - page 3

Nouveau commentaire
 

Tout,

La question ici est d'obtenir l'horodatage du tick, et non l'heure à laquelle le tick arrive au terminal en utilisant GetTickCount() (c'est-à-dire à chaque fois que la fonction start() est appelée), comme suggéré.

MarketInfo(Symbol(), MODE_TIME) renvoie l'horodatage du tick tel qu'il est envoyé par le serveur du courtier dans le flux de données.

Salutations

VS

 
AnkaSoftware:

Tout,

La question ici est d'obtenir l'horodatage du tick, et non l'heure à laquelle le tick arrive au terminal en utilisant GetTickCount() (c'est-à-dire à chaque fois que la fonction start() est appelée), comme suggéré.

MarketInfo(Symbol(), MODE_TIME) renvoie l'horodatage du tick tel qu'il est envoyé par le serveur du courtier dans le flux de données.

Malheureusement, la précision n'est que de 1 seconde.
 
ubzen:

1) GetTickCount(), devrait fonctionner en direct. Inutile sur les données historiques.

2) Même les données mt5_data ne sont pas enregistrées en millisecondes. Cependant, no_problem Live.

3) Je ne vois pas où vous voulez en venir. Si c'est le même temps en millisecondes, alors avoir des millisecondes ne serait pas utile. S'il s'agit de temps différents en millisecondes, alors GetTickCount() pourrait aider. Aider dans le sens où votre code traite le tick actuel en moins d'une milliseconde. L'importance dépend de ce que vous essayez d'accomplir... je suppose.


Merci à tous pour leurs réponses. Il y a un indicateur qui a été posté dans la base de code, Rogue Tick Detector. Mais il n'est pas encore approuvé. Vous pouvez le trouver ici pour le moment.

L'idée de base est qu'il y a des moments où le tick0 actuel arrivera avec un horodatage plus tardif que le tick-1 précédent. Mais le prix ne serait plus actionnable, mais l'EA ou le trader humain ne le saurait qu'après coup. Cela provoquait le déclenchement erroné d'événements basés sur le prix. Un détecteur de tics malveillant était capable de repérer ces faux ticks et d'empêcher l'EA d'agir sur eux (attendre le prochain "bon" tick).

La méthode actuelle de capture de l'horodatage des ticks, MarketInfo(Symbol(), MODE_TIME), ne renvoie pas d'horodatage en millisecondes. Je suis donc venu ici pour demander s'il existait des alternatives que nous avons négligées.

Les EAs qui incluent les fonctions de détection de tick erroné fonctionnent tous sur des VPS à New York avec des disques SSD, Windows 2008, et sont généralement à <2ms du serveur du courtier. Pas de HFT ou d'hyperscalping (la durée moyenne de conservation des transactions est d'environ 1 heure).

Cela me ramène à l'une de mes questions initiales : Comment la plateforme mt4 (et mt5) est-elle censée distinguer correctement les ticks qui arrivent au "même moment" ?

edit, merci ankasoftware pour la clarification.

 
4evermaat:


Cela me ramène à l'une de mes questions initiales : Comment la plateforme mt4 (et mt5) est-elle censée distinguer correctement les ticks qui arrivent au "même moment" ?

Vous ne pouvez pas... votre courtier vous envoie-t-il plusieurs ticks qui arrivent en même temps ? ou incrémente-t-il simplement le compte par 2 et envoie-t-il le dernier tick ? comment pouvez-vous savoir s'il le fait ? êtes-vous conscient qu'il y a une énorme différence dans le compte de tick entre les courtiers ?
 
RaptorUK:
Vous ne pouvez pas... votre courtier vous envoie-t-il plusieurs ticks en même temps ? ou incrémente-t-il simplement le compte par 2 et envoie-t-il le dernier tick ? comment le sauriez-vous si c'était le cas ? êtes-vous conscient qu'il y a une énorme différence dans le compte de tick entre les courtiers ?


Oui, je suis conscient que les différents courtiers ont des flux différents et que le nombre de tick peut être très différent. Mais il se trouve que les ticks erronés sont envoyés à certains moments, principalement lorsque les transactions sont clôturées avec un profit. Cela affectait le déclenchement des closealls et des ordres, nous avons donc trouvé un moyen de les détecter et de les ignorer du mieux que nous pouvons. J'ai même soupçonné une manipulation intentionnelle des flux à un moment donné de la part de certains courtiers.

Mais peut-être devrions-nous avoir un ratio de comptage des tiques, où nous comptons le nombre total de tiques.

Il se peut très bien que cela n'affecte pas beaucoup de personnes, mais j'ai pensé que les dommages potentiels étaient suffisants pour justifier une enquête plus approfondie.

 
Il n'y a pas de fonction/processus qui fait exactement ce que vous demandez [ à ma connaissance ] pour le moment.
4evermaat:Mais peut-être devrions-nous avoir un ratio de comptage des ticks, où nous comptons le total des ticks

Qu'avez-vous en tête ? En quoi cela serait-il différent de mt4 Volume ? Un rapport de deux nombres [ nombre et ? ?? ].

Ce sujet devient très vite confus. Moi-même, je ne sais pas tout sur les ticks, ni comment metaQuotes les traite, ni pourquoi cela sera très critique pour quelqu'un. Permettez-moi de résumer certaines de mes observations.

1) metaQuotes dit : vous voulez un horodatage en milli_secondes, [ ils commencent immédiatement à penser aux données de ticks ], qui va détenir ces données de ticks le courtier ? vous voulez dire que vous dire qu'il y a 200 ticks dans cette minute n'est pas suffisant pour vous ? Vous voulez vraiment que nous sauvions 200 entrées de données parce que OHLC+V n'est pas assez bon ?

2) le trader numéro 1 dit : Je n'ai besoin de personne pour sauvegarder l'information, je veux juste un horodatage de milli_secondes pour déterminer les anciennes données.

3) Le négociant numéro 2 dit : Je n'ai pas besoin que vous sauvegardiez les informations, donnez-moi juste la possibilité de les importer et j'obtiendrai mes propres données.

4) Le négociant numéro 3 dit : Je ne vois pas pourquoi c'est si important de sauvegarder et de fournir des données en tick. Allez, les ordinateurs ont plus de puissance et de mémoire de nos jours, mon courtier peut sûrement fournir les données quelque part.

5) Le courtier répond : J'ai déjà du mal à vous fournir des données m1 depuis plus de 3 mois, qu'est-ce qui vous fait penser que je suis capable ou désireux de fournir autant de données lorsque vous vous connectez ou pour des tests.

6) trader number4 : nous n'en avons pas besoin pour les tests et juste une petite partie pour les données serait suffisante en direct, je ne me plains pas de l'insuffisance de m1 maintenant alors quel est le problème.

7) metaQuotes : toujours pas d'accord, cela signifie que nous devrons faciliter les fonctions qui renvoient les milli_secondes et les indicateurs et autres qui distinguent les ticks ... essayez-vous de faire planter le terminal ou quelque chose ?

8) trader number5 : tu veux dire que Volume n'est pas market_depth mais un compte du nombre de ticks dans une time_frame donnée :) . Vous voulez dire que je peux manquer des ticks ? Vous voulez dire que les ticks peuvent se perdre ou être retardés dans le cyberespace ? Vous voulez dire que le tick_count diffère entre les courtiers ? Vous voulez dire que les données stockées par le courtier n'auraient pas été les mêmes que celles que j'aurais reçues ? Alors, pourquoi cette agitation autour du tick ?

9) xxxxxxxxxxxx dit : tick est top secret, ce qui est fourni est certainement suffisant, j'ai aidé à concevoir le générateur de tick et j'ai très peu d'intérêt à fournir ce genre de résolution. pas question d'arriver.... période.

10) trader number6 : il y a des limitations technologiques, à ce qui peut être fourni, comment le tick count fonctionne, ce qui peut être reçu, etc. Ce n'est pas un problème propre à metaTrader, mais plutôt à toutes les plateformes de détail. Il ne s'agit pas d'un problème propre à MetaTrader, mais plutôt à beaucoup de plateformes de vente au détail.

Trader#3 à Trader#10 : je ne suis pas d'accord.

Ubzen dit : Je ne sais plus quoi dire.

Ps> j'ai failli oublier trader#7 : très bien, je vais enregistrer mes propres tick qui arrivent sur mon terminal et programmer mes propres indicateurs et autres pour traiter ces données... C'est ainsi que j'ai interprété la question et donc pourquoi j'ai recommandé le GetTickCount().

 
ubzen:

Ps> j'ai failli oublier trader#7 : très bien, je vais enregistrer mon propre tick qui arrive sur mon terminal et programmer mes propres indicateurs et autres pour traiter ces données.... C'est ainsi que j'ai interprété la question et c'est pourquoi j'ai recommandé le GetTickCount().

Malheureusement, cela ne permet toujours pas de faire face aux ticks manqués... En pratique, il est impossible de sauvegarder vos propres ticks, vous ne pouvez pas tous les obtenir et comme vous en manquerez certains, à moins que ce fait ne soit enregistré, les données sauvegardées seront incorrectes et potentiellement pires qu'inutiles, elles seront trompeuses.
 
RaptorUK: Malheureusement, cela ne permet toujours pas de faire face aux ticks manqués... En pratique, il est impossible de sauvegarder vos propres ticks, vous ne pouvez pas tous les obtenir et comme vous en manquerez certains, à moins que ce fait ne soit enregistré, les données sauvegardées seront incorrectes et potentiellement pires qu'inutiles, elles seront trompeuses.

J'espère rester dans le sujet ici :). Cela dit, imaginez un courtier qui envoie des timeStamps de quelques millisecondes à chaque tick. Mais, ensuite, il ne sauvegarde pas cette information de son côté. Etant donné le manque de confiance envers les courtiers en général, ce courtier ouvrirait la porte à un assaut de demandes de renseignements. Mais cette fois-ci, les gens ont des preuves en quelques millisecondes, mais le courtier n'a pas d'archives pour y répondre. Donc, dans un certain sens, demander des données de ticks | millisecondes ou autre, ce qui conduit aux mêmes arguments, revient à demander au courtier d'enregistrer les données de ticks et à la plateforme de le faciliter.

Dans un deuxième temps, considérez les back-tests inversés que la plupart des gens font. Vous exécutez une stratégie en direct pendant environ une semaine, puis vous réalisez un back_test sur cette semaine afin de vérifier si vous obtenez les mêmes résultats. Cette personne a des horodatages de millisecondes en direct et des retards et des paquets manquants en direct. Bien sûr, comme l'auteur de la première affiche, vous ignorez les données manquantes et/ou vous écartez les tics retardés. Cependant, lorsque vous effectuez le back-test, toutes les données du courtier avec des timestamps corrects sont là. Cela va évidemment générer des résultats différents de ceux que vous venez de recevoir en direct.

Alors dites-moi, avez-vous été induit en erreur en direct ou êtes-vous induit en erreur pendant le Back_Test ?

Je suis cependant d'accord avec votre déclaration ci-dessus. Imo, tout cela crée un ensemble de paradoxes qui me conduisent à rester à l'écart des processus inter_minutes tous ensemble. La plateforme a des limites, je les accepte et je vais de l'avant.

 
ubzen:
...

Je suis cependant d'accord avec votre déclaration ci-dessus. Je pense que tout cela crée un ensemble de paradoxes qui m'amènent à rester à l'écart des processus inter-minutes. La plateforme a des limites, je les accepte et je vais de l'avant.

;-)
 
angevoyageur:

Temporisateurs, résolution des temporisateurs et développement d'un code efficace

Résolution de la minuterie Windows : Mégawatts gaspillés

Des liens intéressants, merci, qui m'ont conduit aux services de temps à résolution de microseconde pour Windows. J'ai effectué quelques tests basés sur les informations de ces pages.

Mes tests sur un PC Win 7 et un VPS Windows 2012 indiquent que GetTickCount() a toujours une résolution de 15,6 msec (64 interruptions par seconde) indépendamment du réglage de la minuterie du système, alors que la résolution lors de l'obtention du temps en millisecondes en appelant les fonctions GetSystemTime() [ou GetLocalTime()] ou GetSystemTimeAsFileTime() de kernel32.dll est affectée par les réglages de la minuterie du système, et peut donner jusqu'à 0,5 msec de résolution sur les deux machines que j'ai testées.

Résolution de GetTickCount()

Voici le code d'un script pour tester la résolution 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;
    }
}

Cela donne toujours 15 ou 16 (i.e. 15.6) sur les deux machines testées, indépendamment des changements de résolution du timer système mentionnés ci-dessous pour les autres tests.

Résolution GetSystemTime()

Maintenant les choses commencent à devenir intéressantes. Voici le code d'un script pour tester la résolution 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;
    }
  }
}

Cela donne une résolution de 15/16 msecs sur un PC fraîchement démarré sans aucun autre logiciel en cours d'exécution, mais 1 msec si Chrome est en cours d'exécution sur le PC ! Comme l'explique le deuxième lien d'angevoyageur, Chrome règle le minuteur système sur une résolution de 1 msec, comme le font certains autres logiciels.

J'ai trouvé deux petits utilitaires pour régler la résolution du timer système, de sorte qu'une résolution de 1 msec (ou même 0,5 msec) peut être obtenue de manière contrôlée sur une machine proprement démarrée :

Outil de minuterie du système Windows : http://vvvv.org/contribution/windows-system-timer-tool

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

Je préfère le premier des deux, Windows System Timer Tool. Avec cet outil, j'ai pu obtenir de manière fiable une résolution de 1 msec via GetSystemTime(). GetLocalTime() peut également être utilisé de manière similaire.

Le code script ci-dessus est un exemple de l'amélioration du code MT4 grâce aux structs. Dans l'ancien MT4, l'accès à GetSystemTime() nécessitait l'utilisation d'un tableau d'entiers et de nombreuses manipulations de bits.

Résolution de GetSystemTimeAsFileTime()

Enfin, j'ai noté que les services de temps de résolution à la microseconde pour Windows mentionnent que GetSystemTimeAsFileTime() est une fonction plus rapide pour accéder au temps système, et qu'elle nécessite une structure plus petite et plus simple. Ce dernier point est certainement vrai pour le nouveau MT4, car le "struct" peut être réduit à un simple ulong.

Voici le code d'un script pour tester la résolution 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 l'outil Windows System Timer Tool est utilisé pour définir une résolution de 0,5 secondes pour le minuteur système, ce petit script indique une résolution de 5000 (ou parfois 5001) unités de 100 nsecs = 0,5 msecs.

L'utilisation de GetSystemTimeAsFileTiime() est en effet plus simple et peut montrer une résolution plus fine.

Voici quelques photos de l'utilisation de cette fonction.

Après un démarrage propre :

Après un démarrage propre

Avec Timer Tool utilisé pour régler la résolution du timer système à 1 ms :

Avec l'outil de temporisation utilisé pour régler la résolution de la temporisation du système sur 1 ms.

Et avec Timer Tool utilisé pour régler la résolution de la minuterie du système à 0,5 ms :

Avec l'outil de temporisation utilisé pour régler la résolution de la temporisation du système sur 0,5 ms.

Conclusion

La meilleure fonction à utiliser pour obtenir des timings en millisecondes dans MT4 est GetSystemTimeAsFileTiime() appelée comme indiqué dans le script de test ci-dessus, avec un utilitaire tel que Windows System Timer Tool utilisé pour définir la résolution de timer système souhaitée.

1234
Nouveau commentaire
Raison: