Acceptation des ordres SL/TP - page 2

Nouveau commentaire
 
Cette information devrait être envoyée à toutes les méga-HFT de MT, je plaisante)). Le coût du bon marché est le suivant.
 
fxsaber:

Il a été dit à plusieurs reprises dans un autre fil que même le terminal ralentit en raison d'un très grand nombre de facteurs. Par conséquent, un serveur de négociation beaucoup plus complexe est voué à ralentir encore plus. J'espère toujours que l'optimisation algorithmique est encore possible. Même un décalage de 5 ms est déjà très mauvais. Que dire des centaines de millisecondes.

Quant aux comptes de démonstration, ils ne sont pas très intéressants (je peux y déboguer n'importe quel plugin, tester un nouveau matériel, etc.)

Et j'ai trouvé un maximum de 17 ms sur des comptes réels (je ne dis pas que ce n'est pas long, mais ce n'est pas comparable à 30 secondes).

D'où la suspicion d'une configuration de serveurs en cascade.

 
Andrey Khatimlianskii:

Cette démo n'est pas très intéressante (vous pouvez y déboguer n'importe quel plugin, tester un nouveau matériel, ...).

Et sur des comptes réels, j'ai trouvé un maximum de 17 ms (je ne dis pas que ce n'est pas suffisant, c'est juste que ce n'est pas comparable à 30 secondes).

Malheureusement, ils n'ont pas montré combien de commandes ils ont vérifié.

Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading

Acceptation des ordres SL/TP

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

D'où la suspicion d'une configuration de serveurs en cascade.

Le courtier a confirmé le problème et a réussi à le trouver et à le réparer (il sera disponible après le week-end). Mais il est difficile de dire si c'est dû à MT5.


Mais jeter des pierres dans la direction de MT5 peut certainement être fait par cette situation.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Acceptation des ordres SL/TP

fxsaber, 2020.11.25 00:47

Je ne sais pas quoi faire lorsque je négocie sur le terminal, mais j'ai un choix très faible sur le serveur de négociation et je ne sais pas quoi faire lorsque je négocie. C'est-à-dire avec un ping très faible et un seul compte de trading pour le serveur de trading.



Le terminal et le serveur sont sur la même machine. Charge zéro. Une nouvelle prise a obtenu une telle alerte.

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Journal du serveur.

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Accepter letick sur le serveur.


Les données du script complet confirment qu'il y a un problème. Dans le serveur à charge nulle, il y avait un décalage de 4ms.

 
Andrei Trukhanovich:

une autre explosion de cerveau de fxsaber.

C'est particulièrement pénible quand on se rend compte du temps qu'on a perdu. Et que personne ne le fera pour vous.
 

Il semble vraiment que ce soit un problème sur le serveur. Il s'agit d'un compte MT5 de démonstration

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

Sur un compte réel avec le même courtier, le script renvoie zéro résultat. Il y a plus de 3000 transactions sur le compte.

 
Enrique Dangeroux:

Sur un compte réel chez le même courtier, le script renvoie zéro résultat. Il y a plus de 3 000 transactions sur le compte.

C'est suspect. Je n'ai trouvé aucun décalage sur mes comptes.

 

Je ne sais pas si c'est lié. Mais j'en ai beaucoup. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Erreurs qui déclenchent Prendre lorsque la position est modifiée. Donc Take est déclenché, dévie quelques fois, puis se bloque, je change le tp à zéro pour reculer et s'effondrer.


Avant de le changer, je le vérifie

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

Pour que la position ne se fige pas.

 
fxsaber :

C'est suspect. Je n'ai trouvé nulle part dans mes comptes un manque de décalage.

J'ai pensé la même chose, mais une enquête plus poussée a montré qu'il y avait environ 100 fermetures par prise uniquement.

Donc, à une petite taille d'échantillon.

 

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

Acceptation des ordres SL/TP

Enrique Dangeroux, 2020.11.25 17:20

Je ne sais pas si c'est lié. Mais j'en ai beaucoup. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

J'ai aussi tout mon journal dans ces messages. Peut-être qu'après le week-end, la situation changera.

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 16:30

Le courtier a confirmé le problème et a réussi à le trouver et à le corriger (il sera disponible après le week-end). Mais il est difficile de dire si c'est dû à MT5.

 

Considérons schématiquement certains algorithmes de la salle des marchés. Pour simplifier, nous supposerons qu'il n'y a qu'un seul LP(fournisseur de liquidités).


Ordre à cours limité.

  1. Le prix du LP satisfait le prix de l'ordre limite de la salle des marchés.
  2. Gateway envoie cet ordre à cours limité au LP avec un court délai d'expiration.
  3. Si Gateway reçoit une redirection pour une partie du volume limite, Gateway répète tout à partir du point 1 pour le volume restant au cas où le tick de LP a changé pendant le traitement de la limite.

Une bonne passerelle (avec l'algorithme ci-dessus) est indépendante des spécificités de la plateforme de négociation lors de l'exécution du limiteur.

L'algorithme est presque en boucle et indépendant de la plate-forme. La protection anti-spam LP est contenue dans le point 3.


Niveau TP d'un poste ouvert.

  1. Une tique est venue de LP
  2. Le prix est envoyé à MT5 comme un nouveau tick.
  3. Si la position n'est pas bloquée et que le prix du nouveau tick atteint le niveau du TP, MT5 crée un ordre TP.
  4. La passerelle voit qu'un ordre TP est né, verrouille la position et fait p.2 de l'algorithme de l'ordre limite.
  5. S'il reçoit un rejack, alors MT5 envoie l'ordre TP à l'historique avec un statut de rejet. Le poste est déverrouillé.

L'algorithme n'est pas bouclé et dépend de la plate-forme. Il existe une protection contre le spam LP.


Cet algorithme présente deux inconvénients, outre les coûts de communication entre la passerelle et le MT5.

  • Il a été démontré dans ce fil de discussion que la naissance d'un ordre TP (voir point 3) dans MT5 a un décalage. Par conséquent, la probabilité qu'un ordre TP puisse être exécuté est plus faible que s'il n'y avait pas de décalage.
  • Un ordre TP dans MT5 ne peut pas être créé sans un nouveau tick. Cela signifie que si une redirection est reçue, la passerelle ne fera rien tant qu'un nouveau tick ne sera pas arrivé dans MT5, satisfaisant le niveau TP. Et un temps précieux pour essayer d'exécuter le niveau TP est perdu à cause de cela. Cela détériore également le FillRate.


Amélioration.

Smart Gateway dans l'algorithme de niveau TP d'une position ouverte a p.6 :

6. Si un nouveau tick a été reçu de LP pendant la redirection, sa valeur réelle est renvoyée à MT5 comme un nouveau tick - passez à l'étape 2.

Ce point supplémentaire de l'algorithme contient toujours une protection contre le spam LP, mais il trompe MT5 en exécutant le point 3. Et aucun temps précieux n'est perdu en attendant le nouveau tick.


La réalité.

Il découle de ces deux algorithmes (même dans le cas du point 6 du second algorithme) ce qui suit.

Un ordre limité MT5 a un FillRate plus élevé que son équivalent sous la forme d'une position ouverte au niveau TP. C'est la raison pour laquelle nous pouvons souvent rencontrer des situations lors d'un rollover sur le MT5-Hedge où l'ordre limite est exécuté, mais pas sa contrepartie TP. Dans ce cas, un CloseBy est effectué et l'ordre Limit est ré-exécuté avec le volume correspondant.


Conclusion.

Pour augmenter le FillRate dans MT5, transférez les niveaux TP des positions ouvertes dans des ordres limites MT5.

12345678
Nouveau commentaire