Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
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.
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.
colaborar con un agente para encontrar el cuello de botella
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.
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.
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).
OnTick se activa unos milisegundos después de que el tick se escriba en el servidor de operaciones.
Resultado.
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.
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.
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.
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.
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.