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
Identifier une rupture de communication
Je ne sais pas comment faire.
Je ne sais pas comment faire.
Qu'est-ce qui vous fait penser qu'ils arrivent et qu'OnTrade se perd ? Dans la documentation ?
Qu'est-ce qui vous fait penser qu'ils arrivent et qu'OnTrade se perd ? Dans la documentation ?
Parce que Relogin réinitialise le cache historique, qui (je suppose) est dopé par le mécanisme OnTrade.
Je ne sais pas comment faire.
Ne pas sortir du temps d'intertitre de MT5, si possible. Et avec les opérations commerciales par rapport à l'ordre dans le DC sans aide interne, je ne vois rien.
Ne pas sortir du temps d'intertitre de MT5, si possible. Et avec les opérations commerciales par rapport à l'ordre dans le DC sans aide interne, je ne vois rien.
Je ne comprends pas.
Je ne comprends pas.
Oui, quelque chose ne va pas. Le temps intertick est uniquement destiné aux ticks manquants en raison d'une rupture de communication. Et en termes de requêtes et d'exactitude des réponses sur les ordres, les transactions et les états de position, si la réponse est manquée ou modifiée en raison d'une défaillance de la communication et des retards qui en découlent, il ne semble pas y avoir de solutions bon marché. Il n'est pas toujours possible d'effectuer une nouvelle interrogation au prochain tic-tac.
La solution pour moi serait une fonction interne permettant de suivre l'état des transactions/positions en ce qui concerne les ordres d'ouverture, de modification, de fermeture partielle et de fermeture complète d'une position. La demande de suivi du résultat pourrait être définie dans la commande elle-même. Et obtenir le résultat sur le tick actuel et non sur le suivant.
Pouvez-vous me dire ce qu'il faut faire pour que je n'aie pas à faire face à ce problème pendant mes échanges ?
A en juger par le temps de journalisation, tout s'est passé en 7ms.
Si vous voulez avoir une discussion constructive, donnez-nous les conditions complètes du test (serveur, type de compte, nombre de symboles sélectionnés, nombre d'EAs, etc).
Le code de mesure du temps d'exécution de SymbolInfoTick :
Sur le serveur MetaQuotes-Demo (20 symboles sélectionnés, Netting, 4 positions ouvertes) :
131 symboles sélectionnés, 10 positions ouvertes :
A en juger par l'heure des entrées du journal, tout s'est passé en 7ms.
C'est trois EA différents.
Si vous voulez une discussion constructive, donnez toutes les conditions de test dans leur intégralité (serveur, type de compte, nombre de symboles sélectionnés, nombre d'EA, etc.)
Compte réel, serveur RannForex, 16 symboles, graphique M1 ouvert sur chacun d'entre eux (5000 barres maximum), sur chacun d'entre eux un EA est en cours d'exécution, qui accède uniquement à son propre symbole.
Il peut y avoir environ 50 positions et le même nombre d'ordres en même temps. Il n'y a pas d'indicateurs, et seuls CopyTicksRange (ticks frais) et SymbolInfoTick sont utilisés pour obtenir les prix. Il n'y a aucune référence aux bars.
Ce sont trois EA différents qui ont été distribués.
Compte réel, serveur RannForex, 16 symboles, graphique M1 ouvert sur chacun d'entre eux (5000 barres maximum), sur chacun d'entre eux un EA est en cours d'exécution qui accède uniquement à son propre symbole.
Il peut y avoir environ 50 positions et le même nombre d'ordres à la fois.
Si je comprends bien, il n'y a pas d'EA là, mais un stress tester sur chaque symbole. Cela change complètement les choses. Et cela montre la dissimulation des conditions initiales.
C'est-à-dire que 16 threads sur un processeur 8(4+HT) (+N threads de terminaux de travail en parallèle), sans arrêt et sans délai, se décomposent en un objet de base de données de symboles synchronisés. Les verrous de lecture/écriture sont mélangés parce qu'il y a une écriture constante.
Habituellement, dans un tel profil, en fonction de la pente du processeur et de sa maîtrise des threads, chaque thread peut passer de 60% à 80% du temps à attendre.
Et ce, quel que soit le type de tâche.
Si j'ai bien compris, il ne s'agit pas d'un EA, mais d'un stress tester sur chaque symbole.
Mal compris. Chaque EA est purement commercial (dans le testeur, les ticks réels ne ralentissent pas) et ne dépend pas des autres. Toute la logique de négociation est exécutée uniquement en OnTick, pas de spamming d'ordres de négociation, pas de récursion, pas de globalisation et pas de ressources.
OnTrade*, OnBook ne sont pas utilisés. Second timer et OnChartEvent pour le cas où certaines touches sont pressées.
Je suis sûr qu'une implémentation correcte (par vous ou par moi) des instantanés réduira considérablement le nombre d'appels aux fonctions régulières de l'environnement. Par conséquent, les retards seront considérablement réduits.
Je n'ai jamais pensé que ça arriverait. J'étudie la question, car l'implémentation standard de MT5-advisor est boiteuse, malheureusement.