FORTS. Questions relatives à l'application de la loi - page 4
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
Vous pensez donc que la latence (dans le réseau interne) de ~30 ms est normale pour le TM-5 ?
Pourquoi les considérez-vous comme internes ?
1) Regardez dans OnTradeTransaction combien de statuts intermédiaires vous recevez au sujet de la demande.
Chaque transaction commerciale n'est pas un paquet (demande-réponse), mais plusieurs notifications. C'est pour que le terminal sache toujours à quel stade se trouve la demande (par exemple, l'exécution peut prendre beaucoup de temps).
Nous réfléchissons actuellement à la possibilité d'inclure dans MQL5 une fonction distincte permettant de désactiver toutes les notifications de statut intermédiaire, transformant ainsi le système en un simple formulaire. Cela pourrait accélérer l'exécution.
2) Vous passez complètement à côté du deuxième aspect de la communication avec l'échange et de la variabilité de la vitesse d'exécution. Apparemment, vous pensez qu'il y a un 0 connu. Mais il n'y a aucune garantie de vitesse.
Il me semble que c'est 10 fois plus que ce que cela pourrait être.
Il ne faut pas se laisser berner par la vue d'un morceau d'asberg qui dépasse de l'eau.
Permettez-moi de préciser que nous n'avons pas réellement amélioré la vitesse par un facteur de 2, mais que nous avons gagné environ 20-30 ms. 2 n'est pas le double de 1, mais seulement le facteur 1. C'est juste un effet de base faible.
En tout cas, nous continuons à travailler et nous obtiendrons des résultats encore meilleurs.
Pourquoi les considérez-vous comme internes ?
1) Regardez dans OnTradeTransaction combien de statuts intermédiaires vous recevez au sujet de la demande.
Chaque transaction commerciale n'est pas un paquet (demande-réponse), mais plusieurs notifications. C'est pour que le terminal sache toujours à quel stade se trouve la demande (par exemple, l'exécution peut prendre beaucoup de temps).
Nous réfléchissons actuellement à la possibilité d'inclure dans MQL5 une fonction distincte permettant de désactiver toutes les notifications de statut intermédiaire, transformant ainsi le système en un simple formulaire. Cela pourrait accélérer l'exécution.
2) Vous passez complètement à côté du deuxième aspect de la communication avec l'échange et de la variabilité de la vitesse d'exécution. Apparemment, vous pensez qu'il y a un 0 connu. Mais il n'y a aucune garantie de vitesse.
En tout cas, nous continuons à travailler et nous obtiendrons des résultats encore meilleurs.
Oui, car la latence de la machine virtuelle (réseau local) est égale (voire supérieure) à la latence lorsque l'on effectue des transactions depuis son domicile (Internet).
Renat, j'espère vraiment que vous résoudrez ce grave problème.
Je vous souhaite sincèrement bonne chance et à nous (utilisateurs) de ne pas attendre trop longtemps.
P/S Merci beaucoup d'avoir répondu à mes questions.
Et merci beaucoup d'avoir amélioré la vitesse si rapidement !
Forex. Pourquoi de tels délais sur le serveur ? Véritable construction 1010.
Vous voulez dire 104 ms et 146 ms ?
Très probablement entre 24ms et 146ms
bien que les commandes aient quitté le terminal presque au même moment.
Probablement entre 24ms et 146ms
bien que les commandes aient quitté le terminal presque en même temps.
Ce bug "flottant" a été discuté dans le fil de discussion "FORTS big delays when placing orders",
( https://www.mql5.com/ru/forum/19681 ) qui n'est malheureusement pas corrigé dans la version 1035.
Dans ce fil, Renat a dit :
"Le délai de livraison de la réponse flottante occasionnelle au terminal n'a pas encore été pris en charge, nous allons continuer à travailler sur ce point."
Aussi :
"En tout cas, nous continuons à travailler et nous obtiendrons des résultats encore meilleurs."
C'est la différence entre 24 et 146, 30 et 104.
Mais il arrive aussi que le temps d'exécution de tous les ordres augmente considérablement.
Où le commerce allait à ce moment-là.
Je me suis penché sur la question de très près et j'en suis arrivé à la conclusion qu'il est nécessaire d'avoir
après cela, vous pouvez faire quelques tests ...
Le serveur est virtuel, Windows - Server 2012 R, réseau Gigabit, ping 7ms. Le réseau est assez stable.
La charge de la machine virtuelle affectera l'envoi des commandes par lots depuis le terminal (il y aura une différence de temps), mais pas le traitement des commandes sur le serveur MT.
Donnez-moi l'IP de votre serveur et je le vérifierai moi-même.
mt5 vous donne un ordre et la machine virtuelle envoie l'information à la machine physique qui l'envoie à son tour à l'interface réseau.
La première phase est écrite dans le journal comme
(mon avis)
+ à ce moment il est conseillé de faire un ping au serveur -t
+ une autre situation peut être que le serveur MT5 agit comme un tuyau vers un certain PL et à partir de la connexion MT5server - PL et la réaction du PL à l'ordre peut augmenter le temps total.
vous avez besoin de МТ5 serveur comme instance ultime (broker ala market maker)
La commande netstat donne une IP étrange :
Impossible d'identifier l'IP du serveur Europe #1
Peut-être que c'est plus facile de
ouvrir un fichier de compte et de là une image avec le nom du serveur/courtier
C'est toujours suspendu au dernier écran...