MT5 e la velocità in azione - pagina 35

 
fxsaber:

Stanco di fare il debug delle istantanee. Finalmente l'ha reso perfetto. Un consulente, niente. Due - perfetto. 20 - disastro: la CPU è sotto il 100%. HistorySelect ha un ritardo di molti millisecondi.

Sembra che MT5 non sia destinato a gestire molti Expert Advisors allo stesso tempo.

Stai scrivendo uno stress test o un normale Expert Advisor?

Molto probabilmente esattamente uno stress test multi-thread in una singola base. Quindi ripeterò:

Forum sul trading, sistemi di trading automatico e test di strategie di trading

MT5 e la velocità in azione

Renat Fatkhullin, 2020.09.16 12:47

Se ho capito bene, non c'è un EA lì, ma uno stress tester su ogni simbolo. Questo cambia completamente il caso. E mostra il nascondersi delle condizioni iniziali.

Cioè, su 8(4+HT) CPU 16 thread (+N worker terminal threads in parallelo) non stop e senza ritardo si rompono in un oggetto di database di simboli sincronizzato. I blocchi di lettura/scrittura si confondono perché c'è una scrittura a tick costante.

Di solito in un tale profilo, a seconda della ripidità del processore e della sua padronanza dei thread, ogni thread può passare dal 60% all'80% del tempo in attesa.

E questo indipendentemente dal tipo di compito.

Se si sta effettivamente avendo una battaglia non-stop per una risorsa in 20 fili, ci sono diverse opzioni:

  1. disaccoppiano logicamente l'accesso e non si impegnano in prove di stress
  2. andare nella propria cache (variante del punto 1)
  3. Aggiornate il vostro hardware (non fatevi ingannare dal fatto che i7 2600k non è male - è male)


Leggete attentamente la scatola. Se N threads colpiscono un singolo oggetto sync, l'attesa vuota sarà al 60-80%.

E il limite dell'efficienza multi-thread sarà da qualche parte intorno agli 8-12 thread. Man mano che il numero di thread aumenta, la frequenza di campionamento diminuisce. Su 2600k il limite di efficienza è ancora più basso.

 
Renat Fatkhullin:

Stai scrivendo uno stress test o un normale lavoro da esperto?

Ordinario

Piuttosto, è uno stress test multi-threaded in una singola base. Quindi ripeterò:

Se infatti state facendo una battaglia non-stop per una singola risorsa in 20 thread, ci sono diverse opzioni:

  1. disaccoppiano logicamente l'accesso e non si occupano dello stress test
  2. andare nella propria cache (variante del punto 1)
  3. Aggiornate il vostro hardware (non fatevi ingannare dal fatto che i7 2600k non è male - è male)


Leggete attentamente la scatola. Se N threads colpiscono un singolo oggetto sync, l'attesa vuota sarà al 60-80%.

E il limite dell'efficienza multi-thread sarà da qualche parte intorno agli 8-12 thread. Man mano che il numero di thread aumenta, la frequenza di campionamento diminuisce. Su 2600k il limite di efficienza è ancora più basso.

Caching completo della storia. Ma anche questo richiede di chiamare HistorySelect(0, INT_MAX).

Come esperimento, ho tagliato tutte le chiamate alla storia necessarie per la logica di trading. Il carico sulla CPU è diminuito molto.


In generale, se ci sono 20 robot, chiamarli in tutta la storia significa che si può causare un disastro con un solo terminale. Di diversi terminali non possiamo nemmeno parlare.

E sembra che l'oggetto sincro non sia solo storia. SymbolInfoTick, CopyTicks e qualcos'altro, sembra.

Comunque, non riesco nemmeno a far funzionare cinque terminali con una dozzina di robot su ciascuno.

Guardare il profilatore di frenata è un peccato.

 
fxsaber:

Ordinario

Caching completo della storia. Ma anche questo richiede di chiamare HistorySelect(0, INT_MAX).

Come esperimento, ho tagliato tutte le chiamate storiche necessarie per la logica di trading. Il carico sulla CPU è diminuito molto.


In generale, se ci sono 20 robot, chiamarli in tutta la storia causerà un disastro con un solo terminale. Di diversi terminali non possiamo nemmeno parlare.

E sembra che l'oggetto sincro non sia solo storia. SymbolInfoTick, CopyTicks e qualcos'altro, sembra.

Comunque, non riesco nemmeno a far funzionare cinque terminali con una dozzina di robot su ciascuno.

Guardare il profilatore di frenata è un peccato.

Nessuna prova, né dati numerici.

1) Quante volte al secondo ogni EA fa delle query di HistorySelect?

2) Esattamente quali funzioni stanno rallentando?

3) Registri?

4) Qual è il principio dei robot?

 
fxsaber:

Tutto sommato, se ci sono 20 robot, affrontare la storia in essi significa provocare un disastro con un solo terminale. I terminali multipli sono fuori questione.

Forse al contrario - ogni terminale supporterà il proprio oggetto synchro, e non ci sarà una coda di 20 EAs ad esso?

Provate ad eseguire 1 robot su 1 terminale, sarà interessante vedere il risultato.

 
Andrey Khatimlianskii:

Forse al contrario - ogni terminale supporterà il proprio oggetto sync e non ci sarà una coda di 20 EAs ad esso?

Provate ad eseguire 1 robot su 1 terminale, è interessante vedere il risultato.

Purtroppo, il risultato di questo esperimento non risponderà alla domanda: cosa fare?

 
fxsaber:

Purtroppo, il risultato di questo esperimento non risponderà alla domanda: cosa fare?

Riconsiderare il concetto di robot di trading

Aggiunto

Ho 3 terminali su reale + 1 demo in cui lavoro

Ogni terminale ha 42 robot che usano OnBoorEvent da 3 a 4 caratteri,

In più ogni 0,5 sec il timer scatta + ogni robot accede alle variabili globali del terminale,

e utilizza 8,34 GB di 32 GB di RAM e il 6,7% di CPU

E niente rallenta, tranne il server TM5 all'inizio delle sessioni di trading.

 
Renat Fatkhullin:

Non ci sono prove, né dati numerici.

1) Quante volte al secondo ogni esperto fa delle query di HistorySelect?

2) Quali funzioni esattamente stanno rallentando?

3) Registri?

4) Qual è il principio alla base dei robot?

È molto difficile per me rispondere a queste domande, perché nemmeno io riesco a capire cosa sta rallentando. Il profiler non funziona nemmeno. Le loro misurazioni stanno imbrogliando, perché il ritardo viene già dalla CPU. Ridurre l'accesso alle funzioni d'ambiente tramite snapshot e caching, purtroppo, non ha dato l'effetto sperato. Sto aspettando un profiler, che sarà in grado di compilare l'Expert Advisor.


Mentre ero occupato, ho trovato un tale casino nello Strategy Tester con la storia degli scambi.

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
  }  
}


Il risultato è

        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


Non ho quasi notato questo bug e ho cercato di scrivere un replay per più di un'ora. Il codice è idiota ma mostra il problema. Se c'è qualcosa di simile non nel Tester ma nel Terminale, non lo so.

Stringa di ricerca: Oshibka 013.


ZS b2626 - fissato.

 
prostotrader:

Riconsiderare il concetto di robot di trading

Un solo robot che scambia tutti i simboli?

 
fxsaber:

Un solo robot che scambia tutti i simboli?

Robot diversi, ma tutti costruiti più o meno sullo stesso modello.

Ci sono 42 lavori coinvolti in un terminale alla volta, e su tre, 126 sono circa 400 simboli

Aggiunto

Per ripetere (io)

Ogni robot usa OnBoorEvent da 3 a 4 caratteri,

più ogni 0,5 sec si attiva un timer + ogni robot accede allevariabili globali del terminale,

8,34 GB di 32 GB di RAM e 6,7% di utilizzo della CPU

E niente rallenta, tranne il server TM5 (o l'hardware Openreach) all'inizio delle sessioni di trading.

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

Robot diversi, ma tutti costruiti più o meno secondo lo stesso schema.

Ci sono 42 lavori coinvolti in un terminale alla volta, e su tre - 126 sono circa 400 caratteri

Aggiunto

Per ripetere (io).

Ogni robot usa OnBoorEvent da 3 a 4 caratteri,

più ogni 0,5 sec si attiva un timer + ogni robot accede allevariabili globali del terminale,

8,34 GB di 32 GB di RAM e 6,7% di utilizzo della CPU

E niente sta rallentando, tranne il server TM5 (o il ferro di Open) all'inizio delle sessioni di trading.

Ecco la cosa strana: per me è il contrario.

Il mio dispositivo ha 4 terminali, ho ridotto il numero di Expert Advisors a circa 200, ho tagliato tutti gli OnBooks, sono tornato a OnTick e ho aggiornato il mio hardware ma i problemi sono gli stessi di fxsaber.

Ma non ci sono lag al mattino nel mio Opener già da molto tempo. E come erano una volta! Fino a 75 secondi a volte :)