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
Cansado de depurar las instantáneas. Finalmente lo hizo perfecto. Un asesor, nada. Dos - perfecto. 20 - desastre: la CPU está por debajo del 100%. HistorySelect se retrasa muchos milisegundos.
Parece que MT5 no está pensado para operar muchos Asesores Expertos al mismo tiempo.
¿Está escribiendo una prueba de esfuerzo o un Asesor Experto habitual?
Lo más probable es que sea exactamente una prueba de esfuerzo multihilo en una sola base. Así que lo repetiré:
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
MT5 y Speed en acción
Renat Fatkhullin, 2020.09.16 12:47
Si entiendo bien, no hay un EA allí, sino un probador de estrés en cada símbolo. Esto cambia el caso por completo. Y muestra la ocultación de las condiciones iniciales.
Es decir, en 8(4+HT) CPU 16 hilos (+N hilos de terminal de trabajador en paralelo) sin parar y sin retraso irrumpen en un objeto de base de datos de símbolos sincronizado. Los bloqueos de lectura/escritura se confunden porque hay una escritura constante de ticks.
Por lo general, en un perfil de este tipo, dependiendo de la inclinación del procesador y su dominio de los hilos, cada hilo puede pasar del 60% al 80% del tiempo de espera.
Y esto es así independientemente del tipo de tarea.
Si en realidad estás teniendo una batalla ininterrumpida por un recurso en 20 hilos, hay varias opciones:
Lea atentamente la caja. Si N hilos golpean un solo objeto de sincronización, la espera vacía estará al 60-80%.
Y el límite de la eficiencia multihilo estará en algún lugar alrededor de 8-12 hilos. A medida que aumenta el número de hilos, la frecuencia de muestreo disminuye. En 2600k el límite de eficiencia es aún menor.
¿Está escribiendo una prueba de esfuerzo o un trabajo pericial ordinario?
Ordinario
Se trata más bien de una prueba de esfuerzo de varios hilos en una sola base. Así que lo repetiré:
Si de hecho estás haciendo una batalla sin parar por un solo recurso en 20 hilos, hay varias opciones:
Lea atentamente la caja. Si N hilos golpean un solo objeto de sincronización, la espera vacía estará al 60-80%.
Y el límite de la eficiencia multihilo estará en algún lugar alrededor de 8-12 hilos. A medida que aumenta el número de hilos, la frecuencia de muestreo disminuye. En 2600k el límite de eficiencia es aún menor.
Almacenamiento total del historial en caché. Pero incluso esto requiere llamar a HistorySelect(0, INT_MAX).
Como experimento, recorté todas las llamadas al historial necesarias para la lógica comercial. La carga de la CPU ha disminuido mucho.
En general, si hay 20 robots, llamarlos a todos en el historial significa que puedes causar un desastre con un solo terminal. De varias Terminales ni siquiera podemos hablar.
Y parece que el objeto sincrónico no es sólo historia. SymbolInfoTick, CopyTicks y algo más, parece.
De todos modos, ni siquiera puedo hacer funcionar cinco terminales con una docena de robots en cada una.
Mirar el perfil de la frenada es un fastidio.
Ordinario
Almacenamiento total en caché del historial. Pero incluso esto requiere llamar a HistorySelect(0, INT_MAX).
Como experimento, corté todas las llamadas del historial necesarias para la lógica de la negociación. La carga de la CPU ha disminuido mucho.
Por lo general, si hay 20 robots, llamarlos a lo largo de la historia significa que puedes causar un desastre con un solo terminal. De varias Terminales ni siquiera podemos hablar.
Y parece que el objeto sincrónico no es sólo historia. SymbolInfoTick, CopyTicks y algo más, parece.
De todos modos, ni siquiera puedo hacer funcionar cinco terminales con una docena de robots en cada una.
Mirar el perfil de la frenada es un fastidio.
No hay pruebas, ni datos numéricos.
1) ¿Cuántas veces por segundo realiza cada EA consultas a HistorySelect?
2) ¿Qué funciones se ralentizan exactamente?
3) ¿Registros?
4) ¿Cuál es el principio de los robots?
En definitiva, si hay 20 robots, abordar la historia en ellos es provocar un desastre con un solo terminal. Las terminales múltiples están descartadas.
Tal vez, por el contrario, cada terminal soportará su propio objeto de sincronización, y no habrá una cola de 20 EAs para él?
Intenta ejecutar 1 robot en 1 terminal, será interesante ver el resultado.
Tal vez, por el contrario, cada terminal soportará su propio objeto de sincronización y no habrá una cola de 20 EAs para él?
Intenta ejecutar 1 robot en 1 terminal, es interesante ver el resultado.
Desgraciadamente, el resultado de este experimento no responderá a la pregunta ¿qué hacer?
Desgraciadamente, el resultado de este experimento no responderá a la pregunta ¿qué hacer?
Reconsiderar el concepto de robot de comercio
Añadido
Tengo 3 terminales en real + 1 demo en los que trabajo
Cada terminal tiene 42 robots que utilizan OnBoorEvent de 3 a 4 caracteres,
Además, cada 0,5 segundos el temporizador se dispara + cada robot accede a las variables globales del terminal,
y utiliza 8,34 GB de 32 GB de RAM y 6,7% de CPU
Y nada se ralentiza, excepto el servidor de TM5 al comienzo de las sesiones de negociación.
No hay pruebas ni datos numéricos.
1) ¿Cuántas veces por segundo realiza cada experto las consultas de HistorySelect?
2) ¿Qué funciones se ralentizan exactamente?
3) ¿Registros?
4) ¿Cuál es el principio de los robots?
Me resulta muy difícil responder a estas preguntas, porque ni siquiera yo mismo consigo entender qué es lo que está frenando. El perfilador ni siquiera se ejecuta. Sus mediciones son tramposas, porque el retraso ya viene de la CPU. La reducción del acceso a las funciones del entorno mediante instantáneas y el almacenamiento en caché, por desgracia, no dio el efecto esperado. Estoy esperando un perfilador, que será capaz de compilar el Asesor Experto.
Mientras estaba ocupado, encontré un lío en el Probador de Estrategias con el historial de operaciones.
El resultado es
Apenas he notado este fallo y llevo más de una hora intentando escribir una réplica. El código es estúpido pero muestra el problema. Si hay algo similar no en el Probador sino en el Terminal, no lo sé.
Cadena de búsqueda: Oshibka 013.
ZY b2626 - arreglado.
Reconsiderar el concepto de robot de comercio
¿Un solo robot que negocia todos los símbolos?
¿Un solo robot que negocia todos los símbolos?
Diferentes robots, pero todos construidos más o menos con el mismo patrón.
En un terminal hay 42 puestos de trabajo a la vez, y en tres, 126 son unos 400 símbolos
Añadido
Para repetir (yo)
Cada robot utiliza OnBoorEvent de 3 a 4 caracteres,
además cada 0,5 seg se dispara un temporizador + cada robot accede a lasVariables Globales del terminal,
8,34 GB de 32 GB de RAM y 6,7% de uso de la CPU
Y nada se ralentiza, excepto el servidor TM5 (o el hardware de Openreach) al inicio de las sesiones de negociación.
Diferentes robots, pero todos construidos más o menos según el mismo esquema.
Hay 42 puestos de trabajo en un terminal a la vez, y en tres - 126 son unos 400 caracteres
Añadido
Para repetir (yo).
Cada robot utiliza OnBoorEvent de 3 a 4 caracteres,
además cada 0,5 seg se dispara un temporizador + cada robot accede a lasVariables Globales del terminal,
8,34 GB de 32 GB de RAM y 6,7% de uso de la CPU
Y nada se ralentiza, salvo el servidor de TM5 (o la plancha de Open) al inicio de las sesiones de negociación.
Lo raro es que a mí me pasa lo contrario.
Mi dispositivo tiene 4 terminales, he reducido el número de EAs a unos 200, he cortado todos los OnBooks, he vuelto a cambiar a OnTick y he actualizado mi hardware pero los problemas son los mismos que con fxsaber.
Pero en mi Opener no hay retrasos por la mañana desde hace mucho tiempo. ¡Y lo que solían ser! Hasta 75 segundos a veces :)