Probador de Estrategias de MetaTrader 5 y MQL5 Cloud Network - página 2
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
Aquí es donde se pone más en detalle. Por lo que tengo entendido, hay un núcleo por carrera, pero se puede elegir cuál + es posible ejecutar varios terminales.
Para la ejecución única (no en modo de optimización, pero sí en ejecución única) puede elegir uno de los agentes locales o uno de los remotos (trabajando en modo servidor).
Para una sola ejecución, no se puede seleccionar un agente de la red MQL5 Cloud Network, porque no tiene sentido práctico ni económico.
A grandes rasgos, no tiene sentido inicializar un potente sistema de red MQL5 distribuido con la elevación de la caché y la preparación de los datos para una sola prueba. El objetivo de la red MQL5 Cloud Network es realizar cálculos de optimización masivos.
Para una sola ejecución (no en modo de optimización, sólo una sola pasada), puede seleccionar uno de los agentes locales o uno de los remotos (trabajando en modo servidor).
Para una sola ejecución, no se puede seleccionar un agente de MQL5 Cloud Network, porque no tiene sentido práctico ni económico.
A grandes rasgos, no tiene sentido inicializar un potente sistema de red MQL5 distribuido con la elevación de la caché y la preparación de los datos para una sola prueba. El objetivo de la red MQL5 Cloud Network es realizar cálculos de optimización masivos.
Para una sola ejecución (no en modo de optimización, sólo una sola pasada), puede seleccionar uno de los agentes locales o uno de los remotos (trabajando en modo servidor).
Para una sola ejecución, no se puede seleccionar un agente de MQL5 Cloud Network, porque no tiene sentido práctico ni económico.
A grandes rasgos, no tiene sentido inicializar un potente sistema de red MQL5 distribuido con la elevación de la caché y la preparación de los datos para una sola prueba. El objetivo de la red MQL5 Cloud Network es realizar cálculos de optimización masivos.
Por cierto que el pensamiento - puede ser en términos de "mejora" para hacer tal tipo de "cálculo" preliminar, digamos, haber analizado la velocidad de transferencia (tiempo de subida) de los cachés como menos y los pluses de más núcleos y comparar recibido con sólo el tiempo de prueba local para dar algunos "consejos" - como no tiene sentido para ejecutar en los remotos. De hecho, al principio no es nada evidente.
Por supuesto, el gestor de pruebas tratará de utilizar más agentes locales, luego agentes remotos y después agentes distribuidos para reducir el coste del cálculo.
Además, estamos introduciendo un mecanismo de procesamiento por lotes, que puede reducir casi a cero el impacto de los retrasos en la red cuando se trabaja con agentes remotos.
Es decir, el terminal distribuirá las tareas en bloques de 32-64 ejecuciones a cada agente, lo que reducirá el impacto de los retrasos de la red en el mismo número de veces.
Ejemplo: envié un lote de 32 tareas en 2KB con parámetros para calcular, y recibí un paquete de respuesta de 1KB con resultados de un agente 5 minutos después. El resultado final es un tráfico de red de 3kb con una pérdida de transmisión de aproximadamente 1 segundo en lugar de 32 segundos sin empaquetado.
Gracias por las respuestas, pero muchas cosas siguen sin estar claras.
Для одиночного прогона (не в режиме оптимизации, а именно одиночный проход) можно выбрать одного из локальных агентов или одного из удаленных (работающих в серверном режиме).
Qué significa: ¿"remoto, funcionando en modo servidor"? No entiendo, si se instala un agente en un segundo ordenador utilizando el componente Metatester, ¿es esto? ¿Qué pasa con los remotos que no están en modo servidor, cómo los añado?
Para una sola ejecución, no se puede seleccionar el agente de MQL5 Cloud Network, porque no tiene sentido práctico ni económico.
Aquí es donde necesitamos un superordenador, o más bien un cluster de superordenadores que trabajen como un solo núcleo, como un solo agente, y se requiere una red - nadie tiene un ordenador así en casa. O al menos la posibilidad de conectarse a una máquina potente (es posible, según tengo entendido, si instalo el agente en un ordenador potente, y lo uso desde un portátil durante una única ejecución). Exactamente para una sola carrera. De hecho, resulta ser lo contrario: no tiene sentido práctico utilizar la red MQL5 Cloud Network para cálculos de optimización masivos, si incluso la única ejecución inicial es difícil. La enumeración de variantes es el segundo caso, pero la carrera única no es menos importante, e incluso más para algunas personas.
Si lo he entendido bien, un agente local/remoto + múltiples terminales
Este no está nada claro cómo descifrarlo...
Renat:
Ejemplo: enviado un paquete de tarea de 32 ejecuciones de 2kb con parámetros a calcular y recibido 5 minutos después un paquete de respuesta de 1kb con resultados del agente. El resultado es 3kb de tráfico de red con aproximadamente 1 segundo de pérdida de transmisión en lugar de 32 segundos sin paquete.
Renat:
A grandes rasgos, no tiene sentido inicializar un potente sistema de red MQL5 distribuido con elevación de caché y preparación de datos para una sola prueba. El objetivo de la red MQL5 Cloud Network es realizar cálculos de optimización masivos.
Estoy de acuerdo con eso. Sin embargo, es una lástima que no exista la posibilidad de realizar varias ejecuciones individuales (pruebas) simultáneamente, incluso con varios núcleos en una sola máquina. Para ser más precisos, secuencialmente, por supuesto, pero sin esperar a que se completen las ejecuciones anteriores. Varias versiones del terminal son muy costosas en memoria. Pero si el probador fuera un programa independiente, con la posibilidad de ejecutar varias instancias, sería mejor. Lo ideal es que sea un probador multitarea. Ahora tenemos que retorcernos - escribir un archivo de configuración con listas de parámetros y cargarlos desde un archivo, alimentando al optimizador con un pseudo-contador de variables. No es muy conveniente. Por no mencionar el hecho de que el conjunto completo de resultados de las pruebas (transacciones, en particular) en esta variante también tiene que ser calculado, formateado y volcado en un archivo en el deinit. Por lo tanto, el procesamiento masivo de los resultados de la optimización es bastante complicado en la versión actual del probador. Ni siquiera puedes cargar los resultados de las pruebas de ayer desde un archivo (¡que sí existe!) a la página de "resultados de optimización" para resolverlos teniendo a mano un probador de "un clic". ¿Puede al menos implementar esa posibilidad?
Una cuestión más: entiendo que durante la optimización se tarda bastante en preparar los datos para los agentes. ¿Es posible cargar los agentes no con ejecuciones-tareas individuales, sino con ejecuciones por lotes (8-16-32)? En este caso (imho) podríamos obtener una ganancia tangible en el tiempo total de optimización. Por lo que sé, este esquema se utiliza con éxito en F4 ahora. Creo que se ejecutan varios conjuntos de parámetros en paralelo (podría estar equivocado). Así que me gustaría tener algo similar en Firth. Por lo demás, mi probador de un solo núcleo va muchas veces por detrás del de cuatro núcleos (ya he escrito sobre ello una vez).
//Demasiado tarde. Cuando escribí, Renat ya escribió sobre el procesamiento por lotes de forma afirmativa. Gracias. Muy contento. Esperaremos.
Gracias por las respuestas, pero muchas cosas siguen sin estar claras.
Lo que significa: ¿"Remoto, funcionando en modo servidor"? No entiendo, si instalas un agente en un segundo ordenador utilizando el componente Metatester, ¿es esto? ¿Y qué pasa con el modo remoto, no servidor, cómo lo añado?
Aquí es donde necesitamos un superordenador, o más bien un grupo de superordenadores, que trabajen como un solo núcleo como un solo agente, y una red - nadie tiene una en casa. O al menos la posibilidad de conectarse a una máquina potente (es posible, según tengo entendido, si instalo el agente en un ordenador potente, y lo uso desde un portátil durante una única ejecución). Exactamente para una sola carrera. De hecho, resulta ser lo contrario: no tiene sentido práctico utilizar la red MQL5 Cloud Network para cálculos de optimización masivos, si incluso la única ejecución inicial es difícil. Probar variantes es el segundo caso, pero la carrera individual no es menos importante, e incluso más para algunas personas.
No está nada claro cómo descifrar esto...
1. Una sola ejecución utiliza un solo núcleo, local (su PC) o agente remoto (intranet).
2) Se pueden desactivar algunos núcleos.
3. puede seleccionar un agente específico (un núcleo específico) en el que realizar la prueba.
En teoría, es posible realizar varias "pruebas individuales" al mismo tiempo (pero entonces se necesitarían varios terminales).
PS
En tu caso, con el portátil, deberías desactivar los núcleos locales y hacer la prueba en un ordenador potente (que esté en red local o cuyos recursos estén libres al máximo para las pruebas).
MetaDriver:
¿Es posible cargar los agentes no por tiradas individuales, sino por paquetes de tiradas (8-16-32)? En este caso (en mi opinión) se puede obtener una ganancia tangible en el tiempo total de optimización. Por lo que sé, este esquema se utiliza con éxito en F4 ahora.
Lo que no entiendo es ....