MT5 et la vitesse en action - page 35

Nouveau commentaire
 
fxsaber:

Fatigué de déboguer les instantanés. C'est finalement parfait. Un conseiller, rien. Deux - parfait. 20 - désastre : le CPU est en dessous de 100%. HistorySelect a un retard de plusieurs millisecondes.

Il semble que MT5 ne soit pas prévu pour faire fonctionner plusieurs Expert Advisors en même temps.

Etes-vous en train d'écrire un test de stress ou un conseiller expert habituel ?

Il s'agit très probablement d'un test de résistance multithread dans une base unique. Je vais donc répéter :

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

MT5 et la vitesse en action

Renat Fatkhullin, 2020.09.16 12:47

Si je comprends bien, il ne s'agit pas d'un EA, mais d'un stress tester sur chaque symbole. Cela change complètement l'affaire. Et cela montre la dissimulation des conditions initiales.

C'est-à-dire que, sur 8(4+HT) CPU, 16 threads (+N threads de terminaux de travail en parallèle) décomposent sans arrêt et sans délai un objet de base de données de symboles synchronisés. Les verrous de lecture/écriture sont mélangés parce qu'il y a une écriture constante.

Habituellement, dans un tel profil, en fonction de la pente du processeur et de sa maîtrise des threads, chaque thread peut passer de 60% à 80% du temps à attendre.

Et ce, quel que soit le type de tâche.

Si vous êtes réellement en train de vous battre sans arrêt pour une ressource dans 20 fils, il existe plusieurs options :

  1. découplent logiquement l'accès et n'effectuent pas de tests de stress
  2. aller dans votre propre cache (variante du point 1)
  3. Mettez votre matériel à niveau (ne vous laissez pas berner par le fait que le i7 2600k n'est pas mauvais - il est mauvais)


Lisez attentivement la boîte. Si N threads touchent un seul objet de synchronisation, l'attente à vide sera de 60-80%.

Et la limite de l'efficacité du multithreading se situera quelque part autour de 8-12 threads. Plus le nombre de fils augmente, plus le taux d'échantillonnage diminue. Sur 2600k, la limite d'efficacité est encore plus basse.

 
Renat Fatkhullin:

Rédigez-vous un test de résistance ou un simple travail d'expert ?

Ordinaire

Il s'agit plutôt d'un test de résistance multithread dans une base unique. Je vais donc répéter :

Si, en fait, vous vous battez sans relâche pour une seule ressource dans 20 fils, il existe plusieurs options :

  1. découpler logiquement l'accès et ne pas traiter le test de stress
  2. aller dans votre propre cache (variante du point 1)
  3. Mettez votre matériel à niveau (ne vous laissez pas berner par le fait que le i7 2600k n'est pas mauvais - il est mauvais)


Lisez attentivement la boîte. Si N threads touchent un seul objet de synchronisation, l'attente à vide sera de 60-80%.

Et la limite de l'efficacité du multithreading se situera quelque part autour de 8-12 threads. Plus le nombre de fils augmente, plus le taux d'échantillonnage diminue. Sur 2600k, la limite d'efficacité est encore plus basse.

Mise en cache complète de l'historique. Mais même cela nécessite d'appeler HistorySelect(0, INT_MAX).

A titre expérimental, j'ai coupé tous les appels à l'historique nécessaires à la logique de trading. La charge sur le CPU a beaucoup diminué.


D'une manière générale, s'il y a 20 robots, les appeler dans toute l'histoire signifie que vous pouvez provoquer une catastrophe avec un seul terminal. De plusieurs terminaux dont nous ne pouvons même pas parler.

Et on a l'impression que l'objet synchro n'est pas seulement de l'histoire ancienne. SymbolInfoTick, CopyTicks et quelque chose d'autre, semble-t-il.

De toute façon, je n'arrive même pas à faire fonctionner cinq terminaux avec une douzaine de robots sur chacun.

Regarder le profileur de freinage est une déception.

 
fxsaber:

Ordinaire

Mise en cache complète de l'historique. Mais même cela nécessite d'appeler HistorySelect(0, INT_MAX).

A titre expérimental, j'ai coupé tous les appels à l'historique nécessaires à la logique du trading. La charge sur le CPU a beaucoup diminué.


En règle générale, s'il y a 20 robots, les appeler dans toute l'histoire provoquera un désastre avec un seul terminal. De plusieurs terminaux dont nous ne pouvons même pas parler.

Et on a l'impression que l'objet synchro n'est pas seulement de l'histoire ancienne. SymbolInfoTick, CopyTicks et quelque chose d'autre, semble-t-il.

De toute façon, je n'arrive même pas à faire fonctionner cinq terminaux avec une douzaine de robots sur chacun.

Regarder le profileur de freinage est une déception.

Aucune preuve, ni données chiffrées.

1) Combien de fois par seconde chaque EA effectue-t-il des requêtes HistorySelect ?

2) Quelles sont exactement les fonctions qui ralentissent ?

3) Les journaux ?

4) Quel est le principe des robots ?

 
fxsaber:

En somme, s'il y a 20 robots, alors aborder l'histoire en eux revient à provoquer une catastrophe avec un seul terminal. Les terminaux multiples sont hors de question.

Peut-être au contraire - chaque terminal supportera son propre objet synchro, et il n'y aura pas une file d'attente de 20 EAs vers lui ?

Essayez de faire fonctionner 1 robot sur 1 terminal, il sera intéressant de voir le résultat.

 
Andrey Khatimlianskii:

Peut-être au contraire - chaque terminal supportera son propre objet de synchronisation et il n'y aura pas une file d'attente de 20 EAs vers lui ?

Essayez de faire fonctionner 1 robot sur 1 terminal, c'est intéressant de voir le résultat.

Malheureusement, le résultat de cette expérience ne répondra pas à la question : que faire ?

 
fxsaber:

Malheureusement, le résultat de cette expérience ne répondra pas à la question : que faire ?

Reconsidérer le concept de robot de trading

Ajouté

J'ai 3 terminaux sur le réel + 1 démo dans lesquels je travaille

Chaque terminal compte 42 robots qui utilisent OnBoorEvent de 3 à 4 caractères,

De plus, toutes les 0,5 secondes, un timer se déclenche + chaque robot accède aux variables globales du terminal,

et il utilise 8,34 Go de RAM sur 32 Go et 6,7 % de CPU

Et rien ne ralentit, à l'exception du serveur TM5 au début des sessions de négociation.

 
Renat Fatkhullin:

Il n'y a pas de preuve, ni de données chiffrées.

1) Combien de fois par seconde chaque expert effectue-t-il des requêtes HistorySelect ?

2) Quelles sont exactement les fonctions qui ralentissent ?

3) Les journaux ?

4) Quel est le principe des robots ?

Il m'est très difficile de répondre à ces questions, car moi-même, je n'arrive pas à comprendre ce qui nous ralentit. Le profileur ne fonctionne même pas. Leurs mesures sont trichées, car le décalage provient déjà du CPU. La réduction de l'accès aux fonctions d'environnement via les snapshots et la mise en cache n'a malheureusement pas donné l'effet escompté. J'attends un profileur, qui sera capable de compiler le Conseiller Expert.


Pendant que j'étais occupé, j'ai trouvé un tel désordre dans le testeur de stratégie avec l'historique des transactions.

void OnTick()
{
  static bool FirstRun = true;
    
  if (FirstRun)
  {
    MqlTick Tick;

    if (SymbolInfoTick(_Symbol, Tick) && Tick.ask)
    {
      MqlTradeRequest Request = {0};
      MqlTradeResult Result;
      
      Request.action = TRADE_ACTION_PENDING;
      Request.type = ORDER_TYPE_BUY_LIMIT;
      Request.symbol = _Symbol;
      Request.volume = 1;
      Request.price = Tick.ask - 10000 * _Point;

      if (OrderSend(Request, Result)) // Выставили отложку.
      {
        Request.action = TRADE_ACTION_DEAL;      
        Request.type = ORDER_TYPE_BUY;
        Request.price = Tick.ask;
        
        FirstRun = !OrderSend(Request, Result); // Открыли позицию.
      }
    }
  }

  HistorySelect(0, INT_MAX); // Результат зависит от этой строки.  
}

// Проверяет наличие ордера в истории торгов.
bool CheckTicket( const long Ticket )
{
  return(HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket);
}

#define  PRINT(A) Print(#A + " = " + (string)(A))

void OnDeinit( const int )
{
  if (HistorySelect(0, INT_MAX))
  {
    PRINT(CheckTicket(4)); // true
    PRINT(CheckTicket(3)); // true
    PRINT(CheckTicket(2)); // false
  }  
}


Le résultat est

        AUDCAD : real ticks begin from 2020.07.15 00:00:00
        2020.07.15 00:01:09   buy limit 1 AUDCAD at 0.84993 (0.94914 / 0.94993)
        2020.07.15 00:01:09   market buy 1 AUDCAD (0.94914 / 0.94993)
        2020.07.15 00:01:09   deal #2  buy 1 AUDCAD at 0.94993 done (based on order #3)
        2020.07.15 00:01:09   deal performed [#2  buy 1 AUDCAD at 0.94993]
        2020.07.15 00:01:09   order performed buy 1 at 0.94993 [#3  buy 1 AUDCAD at 0.94993]
        2020.07.15 23:59:58   position closed due end of test at 0.94646 [#3  buy 1 AUDCAD 0.94993]
        2020.07.15 23:59:58   deal #3  sell 1 AUDCAD at 0.94646 done (based on order #4)
        2020.07.15 23:59:58   deal performed [#3  sell 1 AUDCAD at 0.94646]
        2020.07.15 23:59:58   order performed sell 1 at 0.94646 [#4  sell 1 AUDCAD at 0.94646]
        2020.07.15 23:59:58   order canceled due end of test [#2  buy limit 1 AUDCAD at 0.84993]
        final balance 99999653.00 pips
        2020.07.15 23:59:58   CheckTicket(4) = true
        2020.07.15 23:59:58   CheckTicket(3) = true
        2020.07.15 23:59:58   CheckTicket(2) = false


J'ai à peine remarqué ce bug et j'essaie d'écrire un replay depuis plus d'une heure. Le code est stupide mais il montre le problème. Je ne sais pas s'il existe quelque chose de similaire non pas dans le Testeur mais dans le Terminal.

Chaîne de recherche: Oshibka 013.


ZS b2626 - corrigé.

 
prostotrader:

Reconsidérer le concept de robot de trading

Un seul robot qui négocie tous les symboles ?

 
fxsaber:

Un seul robot qui négocie tous les symboles ?

Des robots différents, mais tous construits à peu près sur le même modèle.

Un terminal compte 42 emplois à la fois, et sur trois, 126, soit environ 400 symboles.

Ajouté

Pour répéter (moi)

Chaque robot utilise OnBoorEvent de 3 à 4 caractères,

plus toutes les 0.5 sec un timer est déclenché + chaque robot accède auxVariables Globales du terminal,

8,34 Go de RAM sur 32 Go sont utilisés et 6,7% du CPU est utilisé

Et rien ne ralentit, à l'exception du serveur TM5 (ou du matériel Openreach) au début des sessions de négociation.

Документация по MQL5: Основы языка / Переменные / Глобальные переменные
Документация по MQL5: Основы языка / Переменные / Глобальные переменные
  • www.mql5.com
Глобальные переменные создаются путем размещения их объявлений вне описания какой-либо функции. Глобальные переменные определяются на том же уровне, что и функции, т. е. не локальны ни в каком блоке. Область видимости глобальных переменных - вся программа, глобальные переменные доступны из всех функций, определенных в программе...
 
prostotrader:

Des robots différents, mais tous construits à peu près selon le même schéma.

Il y a 42 travaux impliqués dans un terminal à la fois, et sur trois - 126 est environ 400 caractères

Ajouté

Pour répéter (moi).

Chaque robot utilise OnBoorEvent de 3 à 4 caractères,

plus toutes les 0.5 sec un timer est déclenché + chaque robot accède auxVariables Globales du terminal,

8,34 Go de RAM sur 32 Go et 6,7 % d'utilisation du CPU

Et rien ne ralentit, sauf le serveur TM5 (ou le fer d'Open) au début des sessions de négociation.

Voilà le truc bizarre, c'est le contraire pour moi.

Mon appareil a 4 terminaux, j'ai réduit le nombre d'Expert Advisors à environ 200, j'ai coupé tous les OnBooks, je suis revenu à OnTick et j'ai mis à jour mon matériel mais les problèmes sont les mêmes qu'avec fxsaber.

Mais il n'y a pas de décalage le matin dans mon Opener depuis longtemps déjà. Et ce qu'ils étaient ! Jusqu'à 75 secondes parfois :)

1...282930313233343536373839404142...94
Nouveau commentaire
Raison: