Probador de Estrategias de MetaTrader 5 y MQL5 Cloud Network - página 30
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
Me temo que con 24 agentes en 8 núcleos (4 esencialmente + hypertrading) gastarás todo el rendimiento de la CPU en proporcionar infraestructura.
Exponer un número excesivo de agentes hace que su índice de rendimiento de relaciones públicas descienda drásticamente, lo que se traduce en un múltiplo de la tasa.
Hace tiempo que no uso la nube. Decidí utilizarlo en la selección de parámetros. El trabajo de la nube fue gratamente sorprendente.
Si se tritura un sistema de red distribuida durante mucho tiempo, se obtiene un buen resultado.
En definitiva, es imposible que sea una hora y media.
P. S. Giró la nube sobre la marcha. Debido a la pérdida de Internet, los agentes remotos se retiraron. Luego no quisieron conectarse (estado autorizado; al menos dos generaciones genéticas no se conectaron) - aparentemente, el probador decidió que hay suficiente que hacer en la nube, y dejó descansar a los agentes libres. Desconecta la nube. Los agentes remotos están conectados. Volvió a encender la nube. Terminó con un colgado.
La red necesita ser un poco finalizada para evitar tales situaciones (por ejemplo, para recordar el tiempo máximo de paso y si la espera de paso dura 2 veces más que el tiempo máximo de paso - para iniciar el mismo proceso en el mejor núcleo de local (o remoto)).
+ TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) necesita ser refinada
+ la velocidad de la genética depende de la velocidad del núcleo más débil - si mis núcleos tienen PR - 160-180, y las tareas en la nube se distribuyen a los núcleos hasta 100. Como resultado, en cada generación, mis núcleos tienen que estar inactivos durante un tiempo considerable y esperar las respuestas de la nube para generar una nueva población. Creo que debería eliminar el límite de 100PR y dar prioridad a aquellos agentes cuyo PR sea mayor que el PR del núcleo local más débil (+o núcleo remoto, si está conectado). Si no es así, hay que equilibrar la carga de alguna manera. Por ejemplo, si suponemos que todos los pases se ejecutan en el mismo núcleo a la misma velocidad (en la vida, por supuesto, no es así, pero muchos expertos con algunas suposiciones, puede ser llamado estable en el tiempo de prueba, independientemente de los parámetros). Si el PR del núcleo local es 150 y el PR del núcleo en la nube es 100, entonces el agente local debería recibir 1,5 veces más tareas que el agente en la nube. Alternativamente, si el PR es más bajo, no dé a los agentes en la nube una tarea a la vez, sino que dé una tarea a un rango más amplio de agentes. En este caso, el tiempo de inactividad sería mínimo. En general, me gustaría que se avanzara en esta cuestión
En las últimas 12 horas, la red se ha colgado tres veces más :(
(Y hay agentes con PR < 100 en las revistas de genética)
Por cierto, ¿alguien ha probado a compartir agentes en un ssd? Teniendo en cuenta que mi disco comienza a crujir en 8 agentes, incluso sin tareas, tengo la sospecha de que el recurso ssd se está agotando rápidamente. Y cuando se prueba un EA bastante ligero, la velocidad de computación, la velocidad del disco duro empieza a quedarse estancada. Cuántos terabytes se bombean a la caché es una buena pregunta)
Existe tal letra en el alfabeto (me refiero a ssd), pero no he hecho pruebas específicas: ya que el servidor con tal dispositivo está en la otra punta de la ciudad. Pero, en mi opinión, en cualquier sistema hay una caché de disco, que suaviza el acceso frecuente al disco.
Decidí optimizar una rejilla simple (temporizador 30 seg, nuevo control de barra m1) en todos los ticks para dos pares. Mis 4 núcleos i5 (PR=160-170) y 8 núcleos i7 (PR=170-180) optimizaron durante unas 90 (!) horas.
Luego resultó que los pasajes de i5 son probados 2 veces más lentos (aunque, como ya he escrito varias veces antes, era viceversa - i5 + winxp64 era más rápido que i7 + win7x64). Al principio, reduje la memoria: el i7 tiene más.
Entonces, accidentalmente, eché un vistazo al administrador de tareas y vi que los agentes tienen la prioridad más baja (Baja). Y lo tengo en ambas máquinas. Y aunque he conseguido subir la prioridad a Normal en win7, winxp64bit no lo permite por alguna razón. Durante medio día con las nuevas prioridades en el i7, mi tiempo de prueba se redujo (aparentemente :)) en varias horas.
Estos "retrasos" parecen observarse en las dos últimas compilaciones (o tal vez sólo me lo parece a mí).
Y la prioridad baja es demasiado cruel - si el equipo al menos 12 horas al día puede dar la máxima prioridad a los agentes.
En general, pensé que la prioridad de alguna manera cambia automáticamente dependiendo de la carga de recursos, pero parece que no cambia por sí mismo :(