MT5 y la velocidad en acción - página 35

 
fxsaber:

Cansado de depurar las instantáneas. Finalmente lo hizo perfecto. Un asesor, nada. Dos - perfecto. 20 - desastre: la CPU está por debajo del 100%. HistorySelect se retrasa muchos milisegundos.

Parece que MT5 no está pensado para operar muchos Asesores Expertos al mismo tiempo.

¿Está escribiendo una prueba de esfuerzo o un Asesor Experto habitual?

Lo más probable es que sea exactamente una prueba de esfuerzo multihilo en una sola base. Así que lo repetiré:

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

MT5 y Speed en acción

Renat Fatkhullin, 2020.09.16 12:47

Si entiendo bien, no hay un EA allí, sino un probador de estrés en cada símbolo. Esto cambia el caso por completo. Y muestra la ocultación de las condiciones iniciales.

Es decir, en 8(4+HT) CPU 16 hilos (+N hilos de terminal de trabajador en paralelo) sin parar y sin retraso irrumpen en un objeto de base de datos de símbolos sincronizado. Los bloqueos de lectura/escritura se confunden porque hay una escritura constante de ticks.

Por lo general, en un perfil de este tipo, dependiendo de la inclinación del procesador y su dominio de los hilos, cada hilo puede pasar del 60% al 80% del tiempo de espera.

Y esto es así independientemente del tipo de tarea.

Si en realidad estás teniendo una batalla ininterrumpida por un recurso en 20 hilos, hay varias opciones:

  1. desacoplar lógicamente el acceso y no realizar pruebas de resistencia
  2. ir a su propia caché (variante del punto 1)
  3. Actualiza tu hardware (no te dejes engañar por el hecho de que el i7 2600k no es malo - es malo)


Lea atentamente la caja. Si N hilos golpean un solo objeto de sincronización, la espera vacía estará al 60-80%.

Y el límite de la eficiencia multihilo estará en algún lugar alrededor de 8-12 hilos. A medida que aumenta el número de hilos, la frecuencia de muestreo disminuye. En 2600k el límite de eficiencia es aún menor.

 
Renat Fatkhullin:

¿Está escribiendo una prueba de esfuerzo o un trabajo pericial ordinario?

Ordinario

Se trata más bien de una prueba de esfuerzo de varios hilos en una sola base. Así que lo repetiré:

Si de hecho estás haciendo una batalla sin parar por un solo recurso en 20 hilos, hay varias opciones:

  1. desvinculan lógicamente el acceso y no se ocupan de la prueba de esfuerzo
  2. ir a su propia caché (variante del punto 1)
  3. Actualiza tu hardware (no te dejes engañar por el hecho de que el i7 2600k no es malo - es malo)


Lea atentamente la caja. Si N hilos golpean un solo objeto de sincronización, la espera vacía estará al 60-80%.

Y el límite de la eficiencia multihilo estará en algún lugar alrededor de 8-12 hilos. A medida que aumenta el número de hilos, la frecuencia de muestreo disminuye. En 2600k el límite de eficiencia es aún menor.

Almacenamiento total del historial en caché. Pero incluso esto requiere llamar a HistorySelect(0, INT_MAX).

Como experimento, recorté todas las llamadas al historial necesarias para la lógica comercial. La carga de la CPU ha disminuido mucho.


En general, si hay 20 robots, llamarlos a todos en el historial significa que puedes causar un desastre con un solo terminal. De varias Terminales ni siquiera podemos hablar.

Y parece que el objeto sincrónico no es sólo historia. SymbolInfoTick, CopyTicks y algo más, parece.

De todos modos, ni siquiera puedo hacer funcionar cinco terminales con una docena de robots en cada una.

Mirar el perfil de la frenada es un fastidio.

 
fxsaber:

Ordinario

Almacenamiento total en caché del historial. Pero incluso esto requiere llamar a HistorySelect(0, INT_MAX).

Como experimento, corté todas las llamadas del historial necesarias para la lógica de la negociación. La carga de la CPU ha disminuido mucho.


Por lo general, si hay 20 robots, llamarlos a lo largo de la historia significa que puedes causar un desastre con un solo terminal. De varias Terminales ni siquiera podemos hablar.

Y parece que el objeto sincrónico no es sólo historia. SymbolInfoTick, CopyTicks y algo más, parece.

De todos modos, ni siquiera puedo hacer funcionar cinco terminales con una docena de robots en cada una.

Mirar el perfil de la frenada es un fastidio.

No hay pruebas, ni datos numéricos.

1) ¿Cuántas veces por segundo realiza cada EA consultas a HistorySelect?

2) ¿Qué funciones se ralentizan exactamente?

3) ¿Registros?

4) ¿Cuál es el principio de los robots?

 
fxsaber:

En definitiva, si hay 20 robots, abordar la historia en ellos es provocar un desastre con un solo terminal. Las terminales múltiples están descartadas.

Tal vez, por el contrario, cada terminal soportará su propio objeto de sincronización, y no habrá una cola de 20 EAs para él?

Intenta ejecutar 1 robot en 1 terminal, será interesante ver el resultado.

 
Andrey Khatimlianskii:

Tal vez, por el contrario, cada terminal soportará su propio objeto de sincronización y no habrá una cola de 20 EAs para él?

Intenta ejecutar 1 robot en 1 terminal, es interesante ver el resultado.

Desgraciadamente, el resultado de este experimento no responderá a la pregunta ¿qué hacer?

 
fxsaber:

Desgraciadamente, el resultado de este experimento no responderá a la pregunta ¿qué hacer?

Reconsiderar el concepto de robot de comercio

Añadido

Tengo 3 terminales en real + 1 demo en los que trabajo

Cada terminal tiene 42 robots que utilizan OnBoorEvent de 3 a 4 caracteres,

Además, cada 0,5 segundos el temporizador se dispara + cada robot accede a las variables globales del terminal,

y utiliza 8,34 GB de 32 GB de RAM y 6,7% de CPU

Y nada se ralentiza, excepto el servidor de TM5 al comienzo de las sesiones de negociación.

 
Renat Fatkhullin:

No hay pruebas ni datos numéricos.

1) ¿Cuántas veces por segundo realiza cada experto las consultas de HistorySelect?

2) ¿Qué funciones se ralentizan exactamente?

3) ¿Registros?

4) ¿Cuál es el principio de los robots?

Me resulta muy difícil responder a estas preguntas, porque ni siquiera yo mismo consigo entender qué es lo que está frenando. El perfilador ni siquiera se ejecuta. Sus mediciones son tramposas, porque el retraso ya viene de la CPU. La reducción del acceso a las funciones del entorno mediante instantáneas y el almacenamiento en caché, por desgracia, no dio el efecto esperado. Estoy esperando un perfilador, que será capaz de compilar el Asesor Experto.


Mientras estaba ocupado, encontré un lío en el Probador de Estrategias con el historial de operaciones.

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


El resultado es

        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


Apenas he notado este fallo y llevo más de una hora intentando escribir una réplica. El código es estúpido pero muestra el problema. Si hay algo similar no en el Probador sino en el Terminal, no lo sé.

Cadena de búsqueda: Oshibka 013.


ZY b2626 - arreglado.

 
prostotrader:

Reconsiderar el concepto de robot de comercio

¿Un solo robot que negocia todos los símbolos?

 
fxsaber:

¿Un solo robot que negocia todos los símbolos?

Diferentes robots, pero todos construidos más o menos con el mismo patrón.

En un terminal hay 42 puestos de trabajo a la vez, y en tres, 126 son unos 400 símbolos

Añadido

Para repetir (yo)

Cada robot utiliza OnBoorEvent de 3 a 4 caracteres,

además cada 0,5 seg se dispara un temporizador + cada robot accede a lasVariables Globales del terminal,

8,34 GB de 32 GB de RAM y 6,7% de uso de la CPU

Y nada se ralentiza, excepto el servidor TM5 (o el hardware de Openreach) al inicio de las sesiones de negociación.

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

Diferentes robots, pero todos construidos más o menos según el mismo esquema.

Hay 42 puestos de trabajo en un terminal a la vez, y en tres - 126 son unos 400 caracteres

Añadido

Para repetir (yo).

Cada robot utiliza OnBoorEvent de 3 a 4 caracteres,

además cada 0,5 seg se dispara un temporizador + cada robot accede a lasVariables Globales del terminal,

8,34 GB de 32 GB de RAM y 6,7% de uso de la CPU

Y nada se ralentiza, salvo el servidor de TM5 (o la plancha de Open) al inicio de las sesiones de negociación.

Lo raro es que a mí me pasa lo contrario.

Mi dispositivo tiene 4 terminales, he reducido el número de EAs a unos 200, he cortado todos los OnBooks, he vuelto a cambiar a OnTick y he actualizado mi hardware pero los problemas son los mismos que con fxsaber.

Pero en mi Opener no hay retrasos por la mañana desde hace mucho tiempo. ¡Y lo que solían ser! Hasta 75 segundos a veces :)