MT5 y la velocidad en acción - página 44
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
Más de una vez he visto situaciones en las que el Terminal carga tanto la CPU al 100% que no reacciona a nada.
Entonces miré los registros y vi que había saltos salvajes de ticks en OnTick. Sin embargo, si escribo correctamente un EA, esta situación desastrosa no afectará a los resultados de las operaciones. Lo he analizado específicamente, todo está claro.
Me pregunto hasta qué punto están extendidos los mecanismos para hacer frente a los retrasos en los productos de mercado. No he visto ni una sola vez que se mencione la potencia de la máquina para funcionar. El ping mínimo es un sí.
¿Dónde los lanzabas?
Si en VPS por 2-5 dólares, entonces los retrasos en decenas y cientos de milisegundos son fácilmente atrapados en cualquier función WinAPI apenas seria. Todo se ralentiza a partir del nivel del hipervisor, convirtiendo una máquina virtual en un espectáculo de diapositivas.
Explicado arriba.
No es GetMicrosecondsCount el que se está ralentizando, es el SO el que está cuantificando los recursos de la CPU para cualquier hilo en tu VPS estrangulado. Para cualquier función, cualquier acción, cualquier programa dentro de su UPU.
Bueno, ningún shell de la CPU puede cortar y asignar los recursos de manera justa cuando tiene 20 (eso sigue siendo respetable) sistemas operativos con 1500 hilos de ejecución por copia. Tome 8-16 núcleos y distribúyalos en 20 * 1.500 = 30.000 (treinta mil pistas físicas).
En mi caso (caja virtual con vin7 + 2 núcleos + 16 GB de RAM en un hardware totalmente propio sin nada más en marcha), ¿de dónde salen las 2-3 µs periódicas?
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
MT5 y la velocidad en el combate
Andrey Khatimlianskii, 2020.10.05 10:19
No es realmente una UPU, sino una máquina virtual en un hardware alquilado:
En mi caso (caja virtual con win7 + 2 núcleos + 16GB de RAM en su propio hardware sin nada más girando), ¿de dónde salen las 2-3 µs periódicas?
Ese es el precio de la doble virtualización.
Sobre todo porque VirtualBox no es un hipervisor de tipo Hyper-V en toda regla, sino que vive encima de tu actual sistema operativo de escritorio (¿también de Windows 7?), que tiene una cáscara de la CPU preparada para un caso de uso diferente.
Así que tienes: Windows 7/10 -> VirtualBox -> Windows 7. Esencialmente, dos niveles de virtualización, con el primero que no conoce las aspiraciones de VirtualBox, viéndolo como un programa normal. La asignación de recursos de la CPU (el threadsheduler) está claramente jodida.
Debería serlo: Hyper-V 2016/2019 -> Windows 2016/2019
No es GetMicrosecondsCount lo que se está ralentizando, es el SO el que está cuantificando los recursos de la CPU para cualquier hilo en tu VPS estrangulado. Para cualquier función, cualquier acción, cualquier programa dentro de su UPU.
Creo que un argumento como este te hará pensar. Asesor.
Así que lejos de ralentizarlo todo. Por eso pude cambiar a winmm::timeBeginPeriod(1)+winmm::timeGetTime() de forma bastante inofensiva, consiguiendo una velocidad como la de GetTickCount, pero sin el temido límite de 16 ms. Sin embargo, los productores del mercado no pueden hacerlo, ya que se trata de una DLL. Es poco probable que hagas una versión regular de un milisegundo.
La función MQL5 para minimizar todas las ventanas y la propia aplicación es una gran idea. Trabajaremos en ello.
Aquí hay otra cosa.
terminal en un VPS, entonces se opondrá fuertemente a que todo se vuelque abruptamente. Él mismo puede y debe minimizar las ventanas si sale de la sesión RDP.
Este es un ejemplo de lo que quería decir.
Ambos servidores son diferentes corredores, están en la misma zona, pueden estar en la misma ubicación.
La tarjeta de servicio sugiere que AMP se encuentre en el Reino Unido.
Y para Just por alguna razón ofrece en NL.
¿Por qué? Si hay un vpc más cercano.
Creo que encontrarás un argumento que te hará pensar. Consejero.
Así que lejos de ralentizar las cosas. Por eso pude cambiar a winmm::timeBeginPeriod(1)+winmm::timeGetTime() de forma bastante inofensiva, consiguiendo una velocidad como la de GetTickCount, pero sin el temido límite de 16ms. Sin embargo, los productores del mercado no pueden hacerlo, ya que se trata de una DLL. Es poco probable que hagas una versión regular de un milisegundo.
Pues eres un maestro de las pruebas de estrés de carrera sin correlación ni control de razonabilidad.
Por supuesto, la medición de microsegundos requiere recursos para poder medir intervalos 1000 veces más pequeños que un milisegundo.
Si de vez en cuando necesitas medir intervalos con mucha precisión, utiliza microsegundos. Y le costará 0 microsegundos.
Si estás preparado para llamar a los millones de veces auto-medida, probablemente estás participando en un auto-engaño.
En un VPS asfixiado, el overclocking del temporizador del sistema a través de timeBeginPeriod es arriesgado. Sólo aumentará la sobrecarga de la CPU:
De lo contrario, el sistema operativo debería haber hecho un GetTickCount/GetTickCount64 preciso hace tiempo y alegrarse de la precisión gratuita. Pero no, tendrás que pagar por la precisión de este temporizador.
Este es un ejemplo de lo que quería decir.
Ambos servidores son de diferentes corredores, están en la misma zona, pueden estar en la misma ubicación.
La tarjeta de servicio sugiere que AMP se encuentre en el Reino Unido.
Y para Just por alguna razón ofrece en NL.
¿Por qué? Si hay una RTPC más cerca.
Conocemos los puntos geográficos de los servidores, y aquí las posiciones de los servidores broker se construyen a partir de bases GeoIP.
Y a menudo ocurre que la información no se corresponde con la realidad. Por lo tanto, nunca debemos suponer que la posición del corredor es exacta.
Mañana estudiaremos esto con más detalle, porque tenemos que volver a comprobar y escanear todo manualmente para responder a la pregunta.
Ese es el precio de la doble virtualización.
Especialmente porque VirtualBox no es un hipervisor completo del tipo Hyper-V, sino que vive sobre su actual sistema operativo de escritorio (¿también Windows 7?) que tiene un shell de CPU adaptado para un caso de uso diferente.
Así que tienes: Windows 7/10 -> VirtualBox -> Windows 7. Esencialmente, dos niveles de virtualización, con el primero que no conoce las aspiraciones de VirtualBox, viéndolo como un programa normal. La asignación de recursos de la CPU (el threadsheduler) está claramente jodida.
Debería serlo: Hyper-V 2016/2019 -> Windows 2016/2019
No, tengo virtualizadores dando vueltas en mi CentOS. Pero no soy competente para continuar este diálogo.