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

[fxsaber]

Andrey Khatimlianskii #:

Por cierto, sí, es interesante. Si un limitador pequeño está en el mismo nivel que el TP de una posición enorme, y ese TP es redirigido porque es grande, el limitador ni siquiera tendrá la oportunidad de ser llenado?

Suposición errónea. La cola de tees expira cuando se envían todas las tees. Es decir, los limitadores están esperando que se envíen todos los tekes, no los resultados de ese envío.

No es la gran cantidad de limitadores lo que puede ralentizar el envío de los mismos, sino la gran cantidad de limitadores al nivel de precio del limitador. Por ejemplo, con un lote mínimo.

[Andrey Khatimlianskii]

fxsaber #:

Suposición errónea. La cola de fichas expira cuando se han enviado todas las fichas. Es decir, los limitadores están esperando que se envíen todos los tekes, no los resultados de ese envío.

No es la gran cantidad de limitadores lo que puede ralentizar el envío de otros limitadores, sino la gran cantidad de limitadores al nivel de precio del limitador. Por ejemplo, con el lote mínimo.

Bueno, al menos de esta manera. Es mejor que ejecutar sistemáticamente todos los TP y los Límites.

Pero hay que arreglar la cola, por supuesto. El TP debería ser un límite regular.

[fxsaber]

Andrey Khatimlianskii #:

Bueno, al menos así es. Es mejor que tener todas las TAs y los límites aplicados de forma consistente.

Pero arreglar la cola, por supuesto, es necesario. El TA debería ser un limitador regular.

Hay muchos más detalles sobre el temaaquí. Con ejemplos.

[fxsaber]

fxsaber #:

Hay muchos más detalles sobre el temaaquí. Con ejemplos.

¡Supuestamente el tick activador de la orden de TP nació después de la orden de TP! Es decir, primero nació la orden de TP, y sólo después el tick que provocó el nacimiento de la orden de TP. Esto parece un delirio. Así que echemos un vistazo detallado a la imagen.

El guión no se ha equivocado, ¡es cierto! Esto significa que la base de datos de ticks se llena con un gran retraso. Y el tiempo de tic se establece como tiempo de grabación. Es decir, el tiempo de tictac erróneo.

Así que se ha encontrado unerror de arquitecturade MT5.

La reproducción de este error en MQ-Demo desde la primera vez.

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define  Bid SymbolInfoDouble(_Symbol, SYMBOL_BID)
#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inTP = 10;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart()
{
  OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, Ask + inTP * _Point);

  OrderSend(_Symbol, OP_SELL, 0.1, Bid, 0, 0, Bid - inTP * _Point);
}

Después de cerrar una posición, nos fijamos en la hora del tick activado y en la hora del tick que debería haber activado la comprobación.

Vemos que el tick se activó 61 ms antes de que apareciera el tick que supuestamente lo activó.

El fallo no sólo se reproduce en MQ-Demo: incluso está presente en las cuentas reales. Pero se puede reproducir inmediatamente en MQ-Demo, como se muestra arriba.

La base de datos de ticks en el servidor de comercio está distorsionada, por desgracia.

Cadena de búsqueda:Oshibka 042.