Aceptación de órdenes SL/TP - página 4

Nuevo comentario
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 sigue siendo un problema actual

La última vez que lo comprobé, este problema estaba resuelto en el mencionado broker.

 

Estimados desarrolladores, por favor, respondan a la siguiente pregunta sobre arquitectura. La información es necesaria para una aplicación de combate. No hay reclamaciones.


Hay dos limitadores con el mismo precio y diferentes lotes. ¿De qué depende su orden en la secuencia de activación?

Tengo varias respuestas a esta pregunta.

  1. En el lote.
  2. En el número de billete.
  3. A partir de la última modificación del precio de apertura.
  4. Desde la última modificación de una orden (por ejemplo, se actualizó el nivel de toma en una orden de Límite).

Si he entendido bien, después de modificar el precio de apertura el limitador se inserta adecuadamente en la tabla-lista de todos los limitadores del servidor, ordenados por precio de apertura. Entonces la respuesta a la pregunta se reduce a si está incrustado al principio de la lista de pedidos con el mismo precio o al final.


La misma pregunta no se refiere a los límites sino a las fichas. ¿De qué depende el orden de activación de fichas idénticas? ¿Es una posición de identificación o algo más?


Permítanme explicar cómo esto podría ayudar en el combate. Por ejemplo, tengo dos limitadores (o tees de posición) al mismo nivel, pero con lotes diferentes. Si la ejecución del límite (tee) depende de la última modificación, entonces puedo aumentar el FillRate simplemente modificando los limitadores aumentando el lote.


Probablemente, sólo alguien que escribió la implementación de la parte correspondiente del servidor de MT5 sabe la respuesta a esta pregunta.

 
Andrei Trukhanovich:

colaborar con un agente para encontrar el cuello de botella

¿Qué es, abejas contra miel?)
 
fxsaber:

Hay dos limitadores con el mismo precio y diferentes lotes. ¿De qué depende su orden en la secuencia de activación?

Tengo varias respuestas a esta pregunta.

  1. En el lote.
  2. En el número de billete.
  3. A partir de la última modificación del precio de apertura.
  4. Desde la última modificación de una orden (por ejemplo, el nivel de toma se actualizó en el límite).

Creo que la variante 4 se utilizó en la cuarta. Es decir, cualquier modificación desplazaba el pedido al final de la cola del nivel de precios correspondiente.

 
secret:
Es como las abejas contra la miel).

en este momento particular en esta situación particular, es mutuamente beneficioso y se ha hecho. una rara coincidencia.

 

Las órdenes TP en MT5 son notables en el sentido de que se puede investigar el FillRate (qué parte de la orden se llena).

El análisis de decenas de miles de órdenes de este tipo ha demostrado que el FillRate depende en gran medida del símbolo. Si un paquete de órdenes TP se activa simultáneamente, entonces el FillRate disminuye a medida que el número de la orden en el paquete aumenta.

También se revelaron otros matices específicos. Pero esto ya se discute con el corredor.


La receta para aumentar el FillRate: combinar todos los mismos ticks y limitadores en un límite común de MT5.


Sin embargo, estos datos no son más que un complemento de este tema. El problema independiente del broker es que MT5 se retrasa con los ticks y en consecuencia con la aceptación de las órdenes pendientes (incluyendo los niveles SL/TP).


Y después de un redireccionamiento, MT5 espera cada vez el siguiente tick para comprobar si el precio satisface el nivel de TP (o límite) o no. Esto puede tardar hasta segundos. Y la comprobación debe hacerse siempre inmediatamente después del reglaje (o del llenado parcial).

Archivos adjuntos:
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick se activa unos milisegundos después de que el tick se escriba en el servidor de operaciones.

// Измеряет размер лага между приходом тика на 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();
    }
  }
}


Resultado.

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


Se procesaron 100 garrapatas. El retardo de llegada entre el servidor y el terminal de garrapatas varía de uno a ocho milisegundos. La media es de poco más de cuatro milisegundos. Esto es igual al retardo de la activación de la orden TP, que es donde comenzó esta rama.


El lag en sí está dentro del servidor de MT5. El canal Servidor->Terminal no tiene nada que ver.


Gran petición a los desarrolladores para que eliminen este retraso. Ahora con cero pings tenemos un retardo constante de ticks entrando no sólo en el terminal, sino también en el Servidor. En particular, la orden acepta.


ZS Para los que desnudan a los corredores de cocina mediante el arbitraje, este retraso incorporado es como maná del cielo. Es decir, los corredores incurren en un riesgo adicional considerable.

 
¿En qué servidor lo has comprobado?

¿En qué herramienta y qué puerta de enlace/datáfono utilizó para formar los datos iniciales?

Si la hora fue generada por un proveedor de cotizaciones en su lado remoto (por ejemplo, la puerta de enlace de la bolsa) y no el propio servidor de MT5, entonces puede haber una brecha.

¿De qué procesos de fondo podría olvidarse, como las pruebas de estrés con decenas y cientos de miles de operaciones paralelas?
 

Renat Fatkhullin:
На каком сервере проверяли?

Comprobado en muchos servidores. Incluyendo MQ-Demo.

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

Aceptación de órdenes SL/TP

fxsaber, 2020.11.25 00:47

Resultado de ejecutarlo en 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
------------------------


El script afirma haber encontrado una orden TP y un tick que fue el desencadenante de su creación (resaltado en color en el texto). Parece que si el precio ha alcanzado el nivel de TP de una posición abierta en el servidor de operaciones (especialmente en la demo), la orden de TP correspondiente debería crearse (no necesariamente ejecutarse) inmediatamente. Sin embargo, en esta situación no ocurrió inmediatamente, sino después de 357 milisegundos.


¿En qué instrumento y en qué puerta/datáfono se formaron los datos iniciales?

He comprobado las herramientas de forex, RannForex-Server, AMTS-gateway. Es necesario aclarar otras configuraciones.

Si el tiempo fue formado por el proveedor de cotizaciones en su lado remoto (por ejemplo, la puerta de enlace de la bolsa), y no el propio servidor MT5, entonces la brecha puede ser.

Creo que el servidor MT5 se estaba formando en una máquina con cero ping. Pero requiere una aclaración para una garantía del 100%. Sin embargo, lo anterior mostró que incluso en su servidor el problema.

 
fxsaber:

Al investigar la ejecución de órdenes TP, me di cuenta de que algunas órdenes TP se creaban con un retraso importante respecto a los ticks que las aceptaban.

El informe mostró que esta situación se repite no sólo en los diferentes corredores, sino también en la situación cuando se negocia en el Terminal, que está en la misma máquina que el Servidor de Comercio. Es decir, con un ping muy bajo y una sola cuenta de trading para el servidor de trading.

Os animo a compartir los resultados de vuestras cuentas. ¡Ayude a mejorar la MT5!

Se ha "olvidado" de un detalle muy pequeño: ha comprobado 58.000 órdenes y sólo ha encontrado un caso de rebasamiento a 300 ms. Este (1 de 58 000) debería haber sido claramente destacado durante estos controles.

Al igual que en las anteriores con cheques millonarios donde también se buscaban valores atípicos individuales y se pretendía que fuera un comportamiento normal.


Comprobamos los registros del servidor y pudimos ver que nuestra virtualización con el servidor MetaQuotes-Demo estaba físicamente enferma en esos segundos (a las 2020.09.30 19:07 durante 4 segundos), porque había unos 15 mln de cuentas y unos 2 mln de posiciones abiertas, y mientras tanto algo estaba ocurriendo en los servidores virtuales e hipervisor vecinos.

En cualquier caso, lo investigaremos más a fondo, aunque siempre hay valores atípicos en cualquier sistema.

12345678
Nuevo comentario