Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Mais je regarde le journal, et le journal montre le même tick avec une différence de 4 secondes.
p.s.
Je déteste la phrase "c'est impossible", je me suis habitué à l'idée que tout peut arriver.
À propos, peut-être est-ce loin du sujet, mais une fois sur l'affirmation que la terre est ronde a également dit quelque chose comme ceci - "ce n'est pas possible".
En général, je suis toujours dans le doute jusqu'à ce que je vérifie, puis revérifie, et de préférence que quelqu'un d'autre revérifie plusieurs fois.
Etes-vous sûr de ne pas vous tromper dans le code qui génère le journal et traite les données ? C'est une différence de 4 secondes.
Les ticks sont déjà dans le terminal, c'est-à-dire qu'ils ont déjà été envoyés sur le réseau.
Mettre le code dans le domaine public
Et voyez par vous-même.
Les tics sont déjà dans le terminal, c'est-à-dire qu'ils ont déjà été transmis sur le réseau.
Mettez-y le code d'accès libre
Et voyez par vous-même.
Merci, je vais faire un essai, je suis le sujet depuis longtemps, je suis plus intéressé en tant que chercheur.
ce code a été décalé de 4 secondes ?
Ça n'a pas l'air d'être celui-là.
je ne vois pas OnTick dans le code
Apparemment, c'était le code en question
J'ai ajouté mon temps au code.
Je me souviens du moment où OnTick() a été déclenché(t_time = GetMicrosecondCount() ;)
Puis je prends le temps, quand chaque fonction est exécutée
Le résultat est
C'est-à-dire que le temps d'exécution de chaque fonction est inférieur à 50 microsecondes!
D'où peuvent venir 4 secondes ?
Je pense que deux EAs étaient en cours d'exécution dans un terminal et que le terminal n'a tout simplement pas le temps de...
Il n'a tout simplement pas le temps de "fusionner" toutes les informations en un seul journal, il fixe donc l'heure locale comme il le juge nécessaire.
En trading, personnellement, j'utilise les ordres asynchrones.
Le fait est que (si vous négociez sérieusement à la Bourse), vous avez besoin de tous les changements du marché boursier,
et le plus tôt cet événement se produira, le mieux ce sera.
Pour ma part, je ne vois pas d'alternative à OnBook.
En principe, il est possible d'alléger l'invocation directe des opérations commerciales à partir d'OnBook. Tout ce que vous avez à faire dans OnBook est de former un drapeau pour exécuter l'opération et de traiter le drapeau lui-même ailleurs. C'est-à-dire que l'opération elle-même devrait être lancée dans une autre procédure par le drapeau formé, qui créera un événement, mais après avoir quitté la procédure HeBook, et alors le code OnBook lui-même sera libéré des opérations lourdes. Toutefois, si les commandes sont ouvertes de manière asynchrone et qu'il n'y a pas de traitement des conditions d'une ampleur démesurée, il est peu probable que cela entraîne des retards importants.
J'ai ajouté mon temps au code.
Je me souviens du moment où OnTick() a été déclenché(t_time = GetMicrosecondCount() ;)
Puis je prends le temps, quand chaque fonction est exécutée
Le résultat est
C'est-à-dire que le temps d'exécution de chaque fonction est inférieur à 50 microsecondes!
D'où peuvent venir 4 secondes ?
Je pense que deux EAs étaient en cours d'exécution dans un terminal et que le terminal n'a tout simplement pas le temps de...
Le terminal n'a tout simplement pas le temps de "vider" toutes les informations dans un fichier journal et c'est pourquoi il définit l'heure locale comme il le juge nécessaire.
Je suppose que c'est vrai, un tel décalage sauvage n'est pas réaliste.
1 - FLUSH a fonctionné quand MQ l'a décidé lui-même !
2 - Retard technique dans l'écriture sur le disque dû à un travail intensif sur le disque dur
Il est possible qu'il y ait déjà une file d'attente d'écriture sur votre machine locale - ce qui est tout à fait réel, j'ai fait l'expérience de plusieurs téraoctets de sauvegarde déversés sur le disque.
Je ne peux que supposer ce qui suit :
Il m'est arrivé de récupérer plusieurs téraoctets de sauvegarde sur le disque, par exemple si j'exécutais Microsoft office, mettais à jour mon Windows et enregistrais des films sur Internet, ou si je travaillais en même temps avec MS SQL sur la machine locale,
faire quelques sauvegardes, avoir une douzaine de 4 torrents et deux ou trois douzaines de programmes qui écrivent intensément sur le disque.
Je veux dire que s'il y a eu un travail intensif avec le disque - c'est possible et il y a eu un retard dans l'écriture du journal sur le disque.
Probablement vrai, mais pas réaliste avec un retard aussi important.
1 - FLUSH a fonctionné quand le MQ a décidé cela de lui-même !
2 - Retard technique dans l'écriture sur le disque causé par un travail intensif sur le disque dur.
Il est possible que votre machine locale soit déjà dans une file d'attente d'écriture, ce qui est faisable. J'ai fait l'expérience de plusieurs téraoctets de données de sauvegarde déversés sur le disque.
Je ne peux que supposer ce qui suit :
J'ai eu plusieurs téraoctets de sauvegarde récupérés sur le disque, par exemple si j'exécutais Mac irosoft office, mettais à jour mon Windows et enregistrais des films depuis Internet, ou si je travaillais en même temps avec MS SQL sur la machine locale,
faire quelques sauvegardes, avoir une douzaine de torrents et deux ou trois douzaines de programmes qui écrivent intensivement sur le disque.
Je veux dire que s'il y a eu un travail intensif avec le disque, il est tout à fait possible qu'il y ait eu un retard dans l'enregistrement sur le disque.
J'ai ajouté mon temps au code.
Je me souviens du moment où OnTick() a été déclenché(t_time = GetMicrosecondCount() ;)
Puis je prends le temps, quand chaque fonction est exécutée
Le résultat est
C'est-à-dire que le temps d'exécution de chaque fonction est inférieur à 50 microsecondes!
D'où peuvent venir 4 secondes ?
Je pense que deux EAs étaient en cours d'exécution dans un terminal et que le terminal n'a tout simplement pas le temps de...
" Par conséquent, il fixe l'heure locale comme il le juge nécessaire.
Au fait - pour ne pas être pris par l'heure d'enregistrement - vous pouvez ajouter l'heure locale au tableau - que vous formez dans le code - ci-dessous
Il y aura alors une différence nette dans le journal entre le moment où le terminal a réinitialisé le journal sur le disque et le moment où le tick ou l'événement d'OnBook est arrivé localement.
Et cela sera plus correct du point de vue de la recherche.
A peine connecté au disque, MT fixe l'heure déjà lors de l'écriture du journal dans son cache. C'est pourquoi j'ai pensé que le terminal en général pendant 4 secondes pouvait être lié à la charge globale du système, plutôt à la RAM et au CPU.
VOUS EN ÊTES SÛR ?
4 secondes ? ???, non ! Pensez-vous vraiment que le processeur est gelé pendant 4 secondes ou que la mémoire a été libérée pendant 4 secondes ?
Il est plus probable qu'il s'agisse de la file d'attente d'écriture sur le disque.
Le disque est plus lent que la mémoire et le processeur.
La commande flush() est une commande C, vous la connaissez probablement et elle est exécutée quand cela vous convient et peut être retardée plus souvent en raison du démarrage du disque.
C'est comme ça qu'on l'appelle quand on veut vider les tampons sur le disque.