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

Nuevo comentario
 
Esta información debería enviarse a todos los mega-HFT de MT, es una broma)) El coste de la baratura es éste.
 
fxsaber:

Se ha dicho repetidamente en otro hilo que incluso el Terminal se ralentiza por un gran número de factores. En consecuencia, un servidor de comercio mucho más complejo está destinado a ralentizar aún más. Todavía espero que la optimización algorítmica sea posible. Incluso un retraso de 5 ms ya es muy malo. Qué decir de los cientos de milisegundos.

Lo de las cuentas demo no es muy interesante (ahí puedo depurar cualquier plugin, probar nuevo hardware, etc.).

Y he encontrado un máximo de 17 ms en cuentas reales (no digo que no sea largo, simplemente no se puede comparar con 30 segundos).

De ahí la sospecha de una configuración de servidores en cascada.

 
Andrey Khatimlianskii:

Eso en la demo no es muy interesante (puedes depurar cualquier plugin allí, probar nuevo hardware, ...).

Y en las cuentas reales encontré un máximo de 17 ms (no digo que no sea suficiente, simplemente no se compara con los 30 segundos).

Desgraciadamente, no mostraron el número de pedidos que comprobaron.

Foro sobre comercio, sistemas de comercio automatizados y prueba de estrategias de comercio

Aceptación de órdenes SL/TP

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

De ahí la sospecha de una configuración de servidores en cascada.

El agente confirmó el problema y consiguió encontrarlo y arreglarlo (estará disponible después del fin de semana). Pero es difícil decir si se debió a MT5.


Pero tirar piedras en la dirección de MT5 definitivamente se puede hacer por esta situación.

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

Aceptación de órdenes SL/TP

fxsaber, 2020.11.25 00:47

No sé qué hacer cuando comercio en el terminal, pero tengo un pick muy bajo en el servidor de comercio y no sé qué hacer cuando comercio en el terminal. Es decir, con un ping muy bajo y una sola cuenta de trading para el servidor de trading.



El terminal y el servidor están en la misma máquina. Carga cero. Una nueva toma consiguió tal alerta.

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Registro del servidor.

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Acepte la marca en el servidor.


Confirmación de los datos de la secuencia de comandos completa de que hay un problema. Dentro del servidor a carga cero había un lag de 4ms.

 
Andrei Trukhanovich:

otra explosión cerebral de fxsaber.

Se siente especialmente mal cuando te das cuenta del tiempo que has perdido. Y que nadie lo hará por ti.
 

Realmente parece ser un problema en el servidor. Esta es una cuenta demo de MT5

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

En una cuenta real con el mismo broker el script devuelve cero resultados. Hay más de 3000 transacciones en la cuenta.

 
Enrique Dangeroux:

En una cuenta real en el mismo broker el script devuelve cero resultados. Hay más de 3.000 transacciones en la cuenta.

Esto es sospechoso. No he encontrado ningún lag en ninguna de mis cuentas.

 

No estoy seguro de que esté relacionado. Pero tengo muchos. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Errores que provocan Tomar cuando se cambia la posición. Así que Take se dispara, se desvía un par de veces, luego se cuelga, cambio tp a cero para retroceder y colapsar.


Antes de cambiarlo, lo compruebo

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

Para que la posición no se congele.

 
fxsaber :

Esto es sospechoso. En ninguna parte de mis cuentas he encontrado la falta de retrasos.

Yo pensé lo mismo, pero una investigación más profunda demostró que había cerca de 100 por los cierres de Take solamente

Por lo tanto, a una muestra pequeña.

 

Foro sobre comercio, sistemas de comercio automatizados y prueba de estrategias de comercio

Aceptación de órdenes SL/TP

Enrique Dangeroux, 2020.11.25 17:20

No estoy seguro de que esto esté relacionado. Pero tengo muchos. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Yo también tengo toda mi bitácora en esos mensajes. Quizá después del fin de semana la situación cambie.

Foro sobre comercio, sistemas de comercio automatizados y prueba de estrategias de comercio

Aceptación de órdenes SL/TP

fxsaber, 2020.11.25 16:30

El agente confirmó el problema y consiguió encontrarlo y solucionarlo (estará disponible después del fin de semana). Pero es difícil decir si se debió a MT5.

 

Consideremos de forma esquemática algunos algoritmos del parqué. Para simplificar, supondremos que sólo hay un LP(proveedor de liquidez).


Orden de límite.

  1. El precio del LP satisface el precio de la orden limitada del parqué.
  2. La puerta de enlace envía esta orden limitada al LP con un tiempo de expiración corto.
  3. Si Gateway recibe una redirección para una parte del volumen límite, Gateway repetirá todo desde el punto 1 para el volumen restante en caso de que el tick del LP haya cambiado durante el tiempo de procesamiento del límite.

Un buen Gateway (con el algoritmo anterior) es independiente de las especificaciones de la plataforma de negociación cuando se ejecuta el Limiter.

El algoritmo es casi en bucle e independiente de la plataforma. La protección contra el spam de LP está contenida en el punto 3.


Nivel de TP de una posición abierta.

  1. Una garrapata ha llegado desde LP
  2. El precio se envía a MT5 como un nuevo tick.
  3. Si la posición no está bloqueada y el precio del nuevo tick cumple con el nivel de TP, MT5 crea una orden de TP.
  4. El Gateway ve que ha nacido una orden TP, bloquea la posición y hace el p.2 del algoritmo de órdenes limitadas.
  5. Si recibe un re-jack, entonces MT5 envía la orden TP al historial con un estado de rechazo. La posición está desbloqueada.

El algoritmo no está en bucle y depende de la plataforma. Tiene protección contra el spam LP.


Este algoritmo tiene dos desventajas, además de los costes de comunicación Puerta-MT5.

  • Se ha demostrado en este hilo que el nacimiento de una orden TP (ver punto 3) en MT5 tiene un retraso. Por lo tanto, la probabilidad de que una orden de TP pueda ejecutarse es menor que si no hubiera retardo.
  • Una orden TP en MT5 no puede ser creada sin un nuevo tick. Esto significa que si se recibe una redirección, el Gateway no hará nada hasta que llegue un nuevo tick a MT5, satisfaciendo el nivel de TP. Y se pierde un tiempo precioso para tratar de ejecutar el nivel de TP debido a esto. Esto también empeora el FillRate.


Mejora.

Smart Gateway en el algoritmo de nivel TP de una posición abierta tiene p.6:

6. Si se ha recibido un nuevo tick desde LP durante el redireccionamiento, su valor real se reenvía a MT5 como un nuevo tick - pasar al paso 2.

Este punto adicional del algoritmo aún contiene protección contra el spam de LP, pero engaña a MT5 para que realice el punto 3. Y no se pierde un tiempo precioso esperando el nuevo tick.


La realidad.

De estos dos algoritmos (incluso en el caso del punto 6 del segundo algoritmo) se deduce lo siguiente.

Una orden limitada de MT5 tiene un FillRate más alto que su equivalente en forma de posición abierta a nivel de TP. Esta es la razón por la que a menudo podemos encontrarnos con situaciones durante un rollover en la MT5-Hedge en las que la orden limitada se ejecuta, pero su contrapartida TP no. En este caso se realiza el CloseBy y se reejecuta la orden de Límite con el volumen correspondiente.


Conclusión.

Para aumentar el FillRate en MT5 transfiera los niveles de TP de las posiciones abiertas a las órdenes limitadas de MT5.

12345678
Nuevo comentario
Razón de la queja: