ForumSections

FORTS. Questions relatives à l'application de la loi - page 91

Nouveau commentaire
fxsaber:

Problèmes uniquement lors de l'annulation de commandes en cours ?


Non, cela se produit dans tous les modes (définir, modifier, annuler).

Heureusement pas si souvent....

prostotrader:

Non, cela se produit dans tous les modes(installer, modifier, annuler).

Lorsqu'il y a un problème pendant l'installation, donnez ce que montrent ORDER_TIME_DONE_MSC et ORDER_TIME_SETUP_MSC.

Lors de l'exécution, il en va de même pour DEAL_TIME_MSC.

Je ne sais pas si quelqu'un a écrit, mais mon ordre ne fonctionne pas toujours lorsque j'entre une transaction sur le marché. J'appuie sur le bouton "Acheter", l'opération se bloque et ne s'ouvre pas, parfois seulement après la troisième ouverture de l'opération. Je suis malheureuse(( L'épandage aimerait aussi qu'il soit moins important, mais c'est une autre histoire. Je suis ravi des promotions et des bonus, cela illumine un peu les inconvénients du terminal ;))

fxsaber:

Lorsqu'il y aura un problème pendant l'installation, donnez ce que montrent ORDER_TIME_DONE_MSC et ORDER_TIME_SETUP_MSC.

Lors de l'exécution, montrer également DEAL_TIME_MSC.


Et que voulez-vous voir en obtenant ORDER_TIME_DONE_MSC, puisqu'il s'agit de l'heure du retrait ou de l'exécution ?

Aujourd'hui (ordre établi, non exécuté)

2017.07.25 10:34:32.675 Trades  'xxxxx': buy limit 2.00 GAZR-6.18 at 12585
2017.07.25 10:34:35.520 Trades  'xxxxx': accepted buy limit 2.00 GAZR-6.18 at 12585
2017.07.25 10:34:35.520 Trades  'xxxxx': buy limit 2.00 GAZR-6.18 at 12585 placed for execution in 2846.102 ms
===============================================================================================================
2017.07.25 10:34:33.695 trader (GAZR-6.18,M1)   CheckOrders: Задержка ответа сервера. Ожидание продолжается...
2017.07.25 10:34:34.702 trader (GAZR-6.18,M1)   CheckOrders: Задержка ответа сервера. Ожидание продолжается...
==============
Ticket = #70456445

Code

ulong ticket = 70456445;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
    if(HistoryOrderSelect(ticket))
    {
      ulong start = ulong(HistoryOrderGetInteger(ticket, ORDER_TIME_SETUP_MSC));
      ulong end = ulong(HistoryOrderGetInteger(ticket, ORDER_TIME_DONE_MSC));
      ulong diff = end - start;
      Print("Order start = ", start);
      Print("Order end = ", end);
      Print("Order diff = ", diff);
    }
   
//---
   return(INIT_SUCCEEDED);
  }

Résultat :

2017.07.25 14:08:03.281 Time_test (GAZR-6.18,M1)        Order start = 1500978875000
2017.07.25 14:08:03.281 Time_test (GAZR-6.18,M1)        Order end =   1500978890000
2017.07.25 14:08:03.281 Time_test (GAZR-6.18,M1)        Order diff =  15000
prostotrader:

Et que voulez-vous voir en obtenant ORDER_TIME_DONE_MSC, puisqu'il s'agit du temps de retrait ou d'exécution ?

Je pensais à l'exécution. Par exemple, vous fixez une limite au prix actuel. Vous pouvez ensuite estimer le temps consacré à l'exécution.

Pour être franc, nous manquons d'informations sur les ordres qui permettraient de savoir quand un ordre a été enregistré par un serveur MT5 et non quand il a déjà été fixé sur une bourse.

fxsaber:

J'ai pensé à l'exécution. Par exemple, en mettant une limite au prix actuel. Vous pouvez ensuite estimer le temps consacré à l'exécution.

Honnêtement, il n'y a pas assez d'informations pour les ordres pour dire quand un ordre a été enregistré par le serveur MT5 et non quand il a déjà été fixé à la bourse.


J'ai contacté le SD au sujet d'une autre entrée de journal indiquant que l'ordre a été accepté par l'échange, et j'ai reçu une réponse :

Support Team 2017.02.28 12:10
Асинхронный метод не ожидает и не отслеживает результат операции (выставление ордера), только сам факт посылки, и соответственно, не протоколирует его.

Ajouté

Mais, le fait est que parfois le serveur traite l'ordre (avant de l'envoyer à l'échange) plus de 2-3 secondes.- est très mauvais...

Ajouté

Habituellement, dans ma configuration, 5-6 ms :

2017.07.25 14:32:40.575 Trades  'ххххх': cancel order #70570407 buy limit 1.00 PLD-12.17 at 806.78
2017.07.25 14:32:40.581 Trades  'ххххх': accepted cancel order #70570407 buy limit 1.00 PLD-12.17 at 806.78
2017.07.25 14:32:40.581 Trades  'ххххх': cancel order #70570407 buy limit 1.00 PLD-12.17 at 806.78 placed for execution in 6.194 ms
prostotrader:

Mais le fait même que le serveur traite parfois l'ordre (avant de l'envoyer à la bourse) pendant plus de 2-3 secondes. - C'est déjà très mauvais...

Il semble que ce soit un bug assez rare. Nous devrions écrire un EA qui met et enlève les limiteurs. Et demandez à SD de l'exécuter en réel en attrapant le bug.

fxsaber:

Il semble que ce soit un bug très rare. Nous devrions écrire un EA qui met et enlève le limiteur. Et demandez au SD de l'exécuter sur le réel en corrigeant les erreurs.


SD fait cela depuis2014.12.16 06:27

prostotrader:

SD fait déjà cela depuis2014.12.16 06:27

Aucune envie de le faire, il semble.

fxsaber:

Sans désir, il semble.


Peut-être... Mais je pense que le désir est là, MAIS !

Le serveur MT5 fonctionne via Plaza II, malheureusement je ne sais pas comment l'interface de MQ est implémentée,

mais en faisant mon interface, je vois qu'avec un très grand flux d'ordres,

Il y a de légers "décalages" dans le traitement des commandes (pour 1 login, il ne devrait pas y avoir plus de 30 opérations par seconde), et imaginez le nombre d'opérations que l'on peut effectuer sur un ordinateur.

les utilisateurs que le courtier a... ?

1...848586878889909192939495969798...156
Nouveau commentaire