MT5 y la velocidad en acción - página 69
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
¿Cómo se prevé esto, el procesamiento paralelo en un hilo?
Un bucle de eventos.
Y en general es un problema del desarrollador porque todo se ejecuta en un hilo.
Resulta que el resumen del mercado se procesa de forma asíncrona, y los manejadores de los programas de usuario, de forma sincrónica.
Es simplemente chicardoso, no hay palabras.
Gracias por los comentarios sobre las estadísticas. Los retrasos de OnTick/OnBook parecen estar ahí para todos. Sleep(1) es 1 ms o 15 ms. No está claro de qué depende.
Todo el mundo parece tener retrasos OnTick/OnBook.
Creo que sabes que OnTimer() no puede ser llamado con más frecuencia que 10-16 milisegundos. Es lógico suponer que otras funciones OnXXX tampoco son llamadas con más frecuencia. ¿Quizá por eso se producen tus retrasos?
Creo que sabes que OnTimer() no puede ser llamado con más frecuencia que 10-16 milisegundos. Es lógico suponer que otras funciones OnXXX tampoco son llamadas con más frecuencia. ¿Tal vez sea esa la razón de tus retrasos?
No lógicamente, los manejadores no están ligados a la frecuencia/resolución del temporizador GetTickCount. Los eventos se activan instantáneamente en el momento en que se producen.
OnTimer tampoco está ligado al error de 16ms. Es fácil conseguir un temporizador de 1ms en la gran mayoría de los casos, a no ser que el ordenador esté muerto y cargado al 100%.
El problema con casi todas las pruebas de fxsaber es que trata de medir los valores atípicos de las llamadas individuales en lugar de promediar el conjunto y no quiere entender la realidad del despachador de hilos.
Lo ha hecho:
Métodos de lucha para acercarse al tiempo de relevo:
En consecuencia, en un VPS normal los terminales (así como cualquier otro programa) siempre sufrirán retrasos inesperados. Cuanto más barato/sobrevendido sea el VPS, más problemas habrá.
Pregúntese en su VPS, ¿está habilitado el SR-IOV y hay algún controlador de red especial más reciente (sólo instalado manualmente) para ello? En el 99% de los casos, no, ya que rompe la migración de las virtualizaciones a través del zoo de hardware. Y sin ella se garantizan retrasos adicionales simplemente por la doble transmisión/procesamiento de paquetes de red (en el host y en el virtual) y el aumento del número de interrupciones.
Nuestro servicio de VPS es mucho menos propenso a esto, tanto en términos de arquitectura como de terminales ligeros sin GUI.
No es lógico, los manejadores no están ligados a la frecuencia/resolución del temporizador GetTickCount. Los eventos se activan instantáneamente en el momento en que se producen.
OnTimer tampoco está vinculado al error de 16ms. Es fácil conseguir un temporizador de 1ms en la gran mayoría de los casos, si el ordenador no está muerto y no está cargado al 100%.
El problema con casi todas las pruebas de fxsaber es que trata de medir los valores atípicos de las llamadas individuales en lugar de promediar el conjunto y no quiere entender la realidad del despachador de hilos.
Lo ha hecho:
Métodos de lucha para acercarse al tiempo de relevo:
En consecuencia, en un VPS normal los terminales (así como cualquier otro programa) siempre sufrirán retrasos inesperados. Cuanto más barato/sobrevendido sea el VPS, más problemas habrá.
Pregúntese en su VPS, ¿está habilitado el SR-IOV y hay algún controlador de red especial más reciente (sólo instalado manualmente) para ello? En el 99% de los casos, no, ya que rompe la migración de las virtualizaciones a través del zoo de hardware. Y sin ella se garantizan retrasos adicionales simplemente por la doble transmisión/procesamiento de paquetes de red (en el host y en el virtual) y el aumento del número de interrupciones.
Nuestro servicio de VPS está sujeto a él por órdenes de magnitud menos, tanto en términos de arquitectura como de terminales ligeros sin GUI.
Y ahora imagina cuántas veces más lento sería el rendimiento de los programas de usuario en una máquina tan optimizada, si los manejadores de los programas se ejecutaran de forma asíncrona.
No entiendo el sentido de la superactualización y la superoptimización del hardware de la máquina, si los manejadores del programa del usuario se ejecutan a priori de forma sincrónica.
Para el propio terminal y su funcionamiento interno, tal vez, sea útil la optimización descrita anteriormente. Para los programas de lucha del usuario, lo dudo.
Porque la ejecución consecutiva de los manejadores en el programa del usuario reduce todo ese potencial de cualquier máquina superoptimizada.
El problema no está en el hardware, sino en la arquitectura del trabajo interno del terminal.
Y ahora imagine cuántas veces más rápida será la ejecución de los programas del usuario en una máquina tan optimizada, si los manejadores de los programas se ejecutan de forma asíncrona.
No entiendo el sentido de la superactualización y la superoptimización del hardware de la máquina, si los manejadores del programa del usuario se ejecutan a priori de forma sincrónica.
Para el propio terminal y su funcionamiento interno, tal vez, sea útil la optimización descrita anteriormente. Para los programas de lucha del usuario, lo dudo.
Porque la ejecución consecutiva de los manejadores en el programa del usuario reduce todo ese potencial de cualquier máquina superoptimizada.
El problema no está en el hardware, sino en la arquitectura de funcionamiento interno del terminal.
No habrá aceleración. Por favor, presente sus cálculos, al menos en cifras aproximadas, demostrando una aceleración múltiple.
¿Una carrera por los recursos? ¿Creación incontrolada de nuevos hilos? ¿Conflictos por nada?
¿Quieres ralentizaciones inexplicables?
En el modelo basado en eventos, todos los eventos han ido siempre en formación, de uno en uno. Masticado - masticado.
Nuestro servicio de VPS es mucho menos propenso a esto, tanto en términos de arquitectura como de terminales ligeros sin interfaz gráfica de usuario.
Si hay retrasos en su servicio VPS, ¿se lo tomará en serio?
Quién utiliza VPS de MQ, por favor comparta los resultados de los siguientes programas allí.
Si hay retrasos en su servicio VPS, ¿se lo tomará en serio?
Me pregunto cuántas veces tendré que decirte que con tantos (miles) hilos por un número limitado de núcleos es una locura hablar de estabilidad de la asignación de quantum de tiempo por hilo.
Siempre está garantizado que habrá fallos en muestras individuales aleatorias de cualquier instrucción, incluyendo las más simples de ensamblador como inc eax. Esto se debe a la arquitectura y a las limitaciones físicas de "asignar honestamente el tiempo de miles de hilos a un pequeño número de núcleos".
Dejen de ser tontos y sigan captando ráfagas individuales por millón de solicitudes.
Dejen de ser estúpidos y sigan atrapando a los que están fuera de lugar por cada millón de consultas.
Ya veo lo que pasa con los picos simples, gracias por la explicación detallada. En este momento no estamos hablando de SymbolInfoTick, sino de lags de otro tipo, que se producen en casi todos los tick.