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

Nuevo comentario
 
fxsaber:

Controla la discrepancia entre TimeLocal y TimeCurrent.

Y si TimeLocal() se retrasa en estas situaciones, ¿la causa está en el sistema operativo?
 
Vasiliy Pushkaryov:
Y si TimeLocal() se retrasa en estas situaciones, ¿la causa está en el sistema operativo?

TimeLocal no se queda atrás. La discrepancia es un corredor.

 
Vasiliy Pushkaryov:

Tal vez alguien ha experimentado, ¿cuál puede ser la razón de tales hipo o frenos?

Lo primero que se me ocurre es un fallo en el código que hace que el cálculo se ejecute durante mucho tiempo (por ejemplo, en el ciclo de 1 a 10 se ejecuta todo el int por culpa del fallo)

 
fxsaber:

TimeLocal no se queda atrás. La discrepancia es un corredor.

Gracias. Lo intentaré.
 
Andrei Trukhanovich:

Lo primero que se me ocurre es un fallo en el código que provoca un cálculo que tarda mucho tiempo (por ejemplo, en el ciclo de 1 a 10 se ejecuta todo el int por culpa del fallo).

Está escrito en la ayuda que un EA en bucle no puede interrumpir el trabajo de otros programas. Todo se congela y luego vuelve a funcionar.

Tengo 7 terminales MT4 y tres terminales MT5 funcionando en paralelo. ¿Quizás no hay suficiente capacidad?



 
Vasiliy Pushkaryov:

Parece que está escrito en la ayuda que un EA en bucle no puede interrumpir otros programas. Y aquí todo se congela, luego todo vuelve a funcionar.

Sí, es extraño, sólo vi la pestaña de expertos, no vi los registros la primera vez.

Hay 7 terminales MT4 y tres terminales MT5 que funcionan en paralelo. ¿Puede ser que no haya suficiente capacidad?

Si es así, lo más probable es que todos los terminales se ralenticen. Además, la carga de la CPU debería escalar al 100% en este caso

 

El conjunto TerminalA - terminales que tienen datos de ping(xxx ms) a los puntos de acceso.

El conjunto TerminalB - terminales que no tienen datos de ping(n/a) a los puntos de acceso.


Los terminales de ambos conjuntos pueden conectarse al mismo punto de acceso y comerciar de la misma manera: se envía el OrderSend y se reciben las respuestas.


El terminalA carga el procesador lo menos posible.


TerminalB:

  • carga la CPU al máximo.
  • después de reiniciar sigue siendo TerminalB.
  • Después de "Rescanear la red" (manualmente a través de la GUI) cambia el tipo a TerminalA. En consecuencia, deja de cargar la CPU.


Si la carga de la CPU es inexplicablemente alta, intente volver a escanear. Esto me ayudó a cambiar toda la TerminalB a la TerminalA.

 

No sé por qué, pero mi broker parece tener más volumen de negocio, número de operaciones y número de cuentas de trading activas en MT5 que en MT4.

Lamentablemente, sólo hay información agregada por plataforma.

Количество закрытых позиций :129 714
Торговый оборот ($) :$ 5 747 296 372
Активных счетов :498

Pero las pruebas circunstanciales sugieren que MT5 está por delante de MT4. Las razones de este estado de cosas sólo pueden adivinarse.


Lo que sé de los clientes:

  • >95% de las operaciones (~99% del volumen de negocio) son automáticas.
  • Algunos clientes tienen el terminal MT5 consumiendo > 10 gigas de memoria (cachés históricas), MT4 con el mismo volumen < 1 giga. A pesar de esto, están dispuestos a pagar de más por un VPS más potente, pero el comercio exactamente en MT5, y no en 4.
  • Casi todos son revendedores. Los principales beneficios se obtienen en las operaciones nocturnas.
  • La alta actividad (en el lado positivo en comparación con otros corredores) durante el período de rollover - enormes spreads.
 
fxsaber TimeCurrent.

Gracias por el consejo. Atrapado en esta situación. En OnTimer() se controla la discrepancia entre TimeLocal() y TimeCurrent()


Desde ayer por la noche a las 21:58 TimeCurrent() empezó a devolver la misma hora. Publicado hoy a las 00:08. Es decir, poco más de dos horas tuvo esta situación de todos los personajes.

 

No una máquina remota (no VPS) con buenas especificaciones y un ping al servidor de comercio <4ms vio muchos casos de lags regulares al ver los registros de Terminal (b2958).


Tomé el primero que vi para la demostración aquí.

2022.01.18 23:00:09.375  Trades  '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.752  Trades  '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.769  Trades  '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms


La modificación del limitador duró ocho segundos. La mayoría de las modificaciones llevan más o menos ese tiempo.

2022.01.18 23:11:00.751 Trades  '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.761 Trades  '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.763 Trades  '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms


Incluso para un ping de 4ms es mucho, pero sigue siendo nada comparado con ocho segundos.


En esta máquina sólo se ejecutan terminales MT5 y la carga media de la CPU es de ~1%. Los análisis han demostrado que, durante el frenado, la carga se dispara hasta el 100% cuando el mercado y las órdenes comerciales son muy activos. Como resultado, se tarda MUCHO tiempo en recibir la respuesta del servidor de comercio al terminal. En el caso de la lentitud he pedido información al corredor. En el lado del servidor comercial todo es instantáneo y la orden llega al servidor desde el terminal en la primera línea. Es decir, el envío de órdenes no se ralentiza, los retrasos se producen al recibir la respuesta al terminal.


Dudo que los desarrolladores puedan mejorar algo aquí. Que es MUY activo en el comercio, por favor, comparta sus observaciones sobre este tema con sus registros.

1...85868788899091929394
Nuevo comentario