Acceptation des ordres SL/TP - page 4

 
Enrique Dangeroux:

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.

  1. Sur le terrain.
  2. Sur le numéro du ticket.
  3. A partir de la dernière modification du prix d'ouverture.
  4. A partir de la dernière modification d'un ordre (par exemple, le niveau de prise a été mis à jour sur un ordre Limit).

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.

 
Andrei Trukhanovich:

collaborer avec un courtier pour trouver le goulot d'étranglement

Qu'est-ce que c'est, les abeilles contre le miel ?)
 
fxsaber:

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.

  1. Sur le terrain.
  2. Sur le numéro du ticket.
  3. A partir de la dernière modification du prix d'ouverture.
  4. A partir de la dernière modification d'un ordre (par exemple, le niveau de prise a été mis à jour à la limite).

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.

 
secret:
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).

Dossiers :
 
fxsaber:

OnTick est déclenché quelques millisecondes après que le tick ait été écrit sur le serveur de transactions.

// Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10;  // EMA-period
input int inAmount = 100; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

  MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


  return((StructToTime(time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0;
int MaxValue = 0;
int MinValue = INT_MAX;
int Amount = 0;

void OnTick()
{
  static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

  MqlTick Tick;
  
  const long time = TimeLocalMsc(); // Локальное время в миллисекундах

  if (SymbolInfoTick(_Symbol, Tick))
  {
    const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax(Value, MaxValue); // Максимальное значение.
    MinValue = MathMin(Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
    if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
    #define  TOSTRING(A) #A + " = " + (string)(A) + "\n"      
      Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST)));
      
      ExpertRemove();
    }
  }
}


Résultat.

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger(TERMINAL_PING_LAST) = 42


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.

 
Sur quel serveur avez-vous vérifié ?

Sur quel outil et quelle passerelle/dataphide avez-vous utilisé pour former les données initiales ?

Si l'heure a été générée par un fournisseur de cotation sur son côté distant (par exemple, une passerelle d'échange) et non par le serveur MT5 lui-même, il peut y avoir un écart.

Quels sont les processus de fond que vous pourriez oublier, comme les tests de résistance avec des dizaines et des centaines de milliers de transactions parallèles ?
 

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.

Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439
Calculation time = 00:00:11.328, Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205
Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0

Orders (2) before 726444166 with PositionID = 725926764:
------------------------
Checked Orders = 0
------------------------


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.

Si le temps a été formé par le fournisseur de cotations sur son côté distant (par exemple, la passerelle d'échange), et non par le serveur MT5 lui-même, alors l'écart peut être.

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.

 
fxsaber:

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.

Raison: