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
https://www.mql5.com/ru/forum/341117 est toujours un problème d'actualité
La dernière fois que j'ai vérifié, ce problème a été résolu sur le courtier mentionné.
Chers développeurs, veuillez répondre à la question suivante sur l'architecture. Les informations sont nécessaires pour une demande de combat. Aucune réclamation.
Il y a deux limiteurs avec le même prix et des lots différents. De quoi dépend leur ordre dans la séquence de déclenchement de l'activation ?
J'ai plusieurs réponses à cette question.
Si je comprends bien, après avoir modifié le prix d'ouverture, le Limiteur est intégré de manière appropriée dans la table de liste de tous les Limiteurs du serveur, triés par prix d'ouverture. La réponse à la question se résume alors à : est-il intégré au début de la liste des commandes ayant le même prix ou à la fin ?
La même question ne porte pas sur les limites mais sur les jetons. De quoi dépend l'ordre de déclenchement des prises identiques ? S'agit-il d'une position d'identification ou d'autre chose ?
Laissez-moi vous expliquer comment cela peut vous aider au combat. Par exemple, j'ai deux limiteurs (ou tees de position) au même niveau, mais avec des lots différents. Si l'exécution de la limite (tee) dépend de la dernière modification, alors je peux augmenter le FillRate simplement en modifiant les limiteurs par incréments de lots croissants.
Probablement, seule une personne ayant écrit l'implémentation de la partie serveur MT5 correspondante connaît la réponse à cette question.
collaborer avec un courtier pour trouver le goulot d'étranglement
Il y a deux limiteurs avec le même prix et des lots différents. De quoi dépend leur ordre dans la séquence de déclenchement de l'activation ?
J'ai plusieurs réponses à cette question.
Je pense que la variante 4 a été utilisée dans le quatrième. C'est-à-dire que toute modification déplaçait la commande à la fin de la file d'attente du niveau de prix correspondant.
C'est comme, les abeilles contre le miel ?)
à ce moment précis, dans cette situation particulière, c'est mutuellement bénéfique et cela a été fait. une rare coïncidence.
Les ordres TP dans MT5 sont remarquables dans la mesure où nous pouvons étudier le FillRate (quelle partie de l'ordre est exécutée).
L'analyse de dizaines de milliers d'ordres de ce type a montré que le FillRate dépend beaucoup du symbole. Si un paquet d'ordres TP est déclenché simultanément, le FillRate diminue à mesure que le nombre d'ordres dans le paquet augmente.
D'autres nuances spécifiques ont également été révélées. Mais ceci est déjà discuté avec le courtier.
La recette pour augmenter le FillRate : combiner tous les mêmes ticks et limiteurs en une limite MT5 commune.
Cependant, ces données ne sont qu'un bonus à ce sujet. Le problème indépendant du courtier est que MT5 est en retard sur les ticks et par conséquent sur l'acceptation des ordres en attente (y compris les niveaux SL/TP).
Et après une redirection, MT5 attend à chaque fois le prochain tick pour vérifier si le prix satisfait ou non le niveau (ou la limite) du TP. Cela peut prendre jusqu'à quelques secondes. Et le contrôle doit toujours être effectué immédiatement après la recharge (ou le remplissage partiel).
OnTick est déclenché quelques millisecondes après que le tick ait été écrit sur le serveur de transactions.
Résultat.
100 tiques ont été traitées. Le décalage d'arrivée entre le serveur et le terminal de saisie varie de une à huit millisecondes. La moyenne est d'un peu plus de quatre millisecondes. C'est juste égal au décalage du déclenchement de l'ordre TP, qui est à l'origine de cette branche.
Le décalage lui-même se trouve à l'intérieur du serveur MT5. Le canal Serveur->Terminal n'a rien à voir avec cela.
Je demande aux développeurs d'éliminer ce décalage. Maintenant, avec zéro pings, nous avons un délai constant de ticks entrant non seulement dans le terminal, mais aussi dans le serveur. En particulier, l'ordre accepte.
ZS Pour ceux qui dépouillent les courtiers en cuisine par l'arbitrage, ce décalage intégré est comme une manne venue du ciel. C'est-à-dire que les courtiers encourent un risque supplémentaire substantiel.
Renat Fatkhullin:
На каком сервере проверяли?
Vérifié sur de nombreux serveurs. Y compris MQ-Demo.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Acceptation des ordres SL/TP
fxsaber, 2020.11.25 00:47
Résultat de l'exécution sur MQ-Demo.
Le script prétend avoir trouvé un ordre TP et un tick qui a été le déclencheur de sa création (surligné en couleur dans le texte). Il semblerait que si le prix a atteint le niveau TP d'une position ouverte sur le serveur de trading (surtout sur la démo), l'ordre TP correspondant devrait être créé (pas nécessairement exécuté) immédiatement. Cependant, dans cette situation, cela ne s'est pas produit immédiatement, mais après 357 millisecondes !
Sur quel instrument et quelle passerelle/dataphide ont été formées les données initiales ?
J'ai vérifié les outils de forex, RannForex-Server, AMTS-gateway. D'autres configurations doivent être clarifiées.
Je crois que le serveur MT5 était formé sur une machine avec un ping nul. Mais exige une clarification pour une garantie de 100%. Cependant, ce qui précède a montré que même sur votre serveur le problème.
En étudiant l'exécution des ordres TP, j'ai remarqué que certains ordres TP étaient créés avec un décalage important par rapport aux ticks qui les avaient acceptés.
Le débriefing a montré que cette situation se répète non seulement sur différents courtiers, mais aussi dans la situation où le trading se fait sur le Terminal, qui se trouve sur la même machine que le Trading Server. C'est-à-dire avec un ping très faible et un seul compte de trading pour le serveur de trading.
Je vous encourage à partager les résultats de vos comptes. Aidez-nous à améliorer le MT5 !Vous avez "oublié" un tout petit détail : vous avez vérifié 58 000 commandes et n'avez trouvé qu'un seul cas de dépassement à 300 ms. Celui-ci (1 sur 58 000) aurait dû être clairement mis en évidence lors de ces contrôles.
Comme dans les cas précédents de chèques d'un million de dollars où vous avez également cherché une seule aberration et prétendu que c'était un comportement normal.
Nous avons vérifié les logs du serveur et nous avons pu voir que notre virtualisation avec le serveur MetaQuotes-Demo était physiquement malade dans ces secondes (à 2020.09.30 19:07 pendant 4 secondes), parce qu'il y avait environ 15 mln comptes et environ 2 mln positions ouvertes, et pendant ce temps quelque chose se passait sur les serveurs virtuels voisins et l'hyperviseur.
Quoi qu'il en soit, nous allons examiner la question de plus près, bien qu'il y ait toujours des cas isolés dans tout système.