Errores de sincronización en la nube - página 3

Nuevo comentario
 
Clock:

Me parece una gran idea y agradezco la insinuación.

Sin embargo, 3 cosas al respecto:

1) Como mencioné anteriormente, también tengo el problema del bucle "interminable", pero como entendí de este hilo que "bucle interminable" es sólo la mejor suposición para "un evento tomó más de diez minutos" acepto que podría ser mi código. Utilizo indicadores bastante complejos, y dado que (al menos eso creo) calculan todo su historial cuando se crea su mango, esto podría (en ordenadores lentos) tardar más de diez minutos.

2) ¡Sin embargo! Por lo general, mi nube se estrelló después de 10-15 minutos. Pero anoche, funcionó perfectamente durante 8 horas. Ni una sola caída, aunque no cambié el código en absoluto. ¡Raro!

3) Y lo más importante, porque está relacionado con su enfoque: Cuando se rechaza un agente en base a su memoria, el agente (y por tanto toda la nube) no se bloquea, lo entiendo. Pero no creo que una máquina más potente vuelva a intentar el mismo conjunto de parámetros, por lo que básicamente se pierden puntos de datos de optimización, ¿estoy en lo cierto? ¿Diría usted que este es el precio que tendremos que pagar?


Tendré curiosidad por ver si mis agentes siguen funcionando cuando vuelva del trabajo...

Hola Reloj,

1) En primer lugar, a no ser que estés utilizando indicadores sobre, digamos, 10 años de datos de 1m y los indicadores sean increíblemente complejos, me sorprendería mucho que en esta época de poder de procesamiento algo tardara incluso 5 minutos en un sistema NORMAL. La razón por la que subrayo lo de normal es que todavía sospecho que hay un número de agentes en la nube que se están ejecutando en máquinas que están extremadamente cargadas o simplemente tienen un mal caso de la depresión de Windows (estrés postraumático). Y sólo hace falta un agente defectuoso para matar tu optimización....

2) Me pasó exactamente lo mismo que a ti, es decir, después de iniciar una optimización, varios agentes de la nube devolvían los resultados sin ningún problema. Luego, después de 5-20 minutos o bastante más a veces, un agente lanzaba el temido error y BANG - fin de la optimización. Y también tuve la optimización ocasional donde se completó sin ningún problema. Es muy frustrante, ya que no tienes ningún acceso a los archivos de registro de los agentes, a los detalles del sistema, al uso de la CPU, etc., para poder ver lo que está pasando.

3) Es un punto muy interesante el que planteas. A mi entender, el optimizador sólo considera que una determinada combinación de parámetros se ha "utilizado" cuando obtiene los resultados de esa combinación de parámetros, aunque podría estar equivocado. ¿Quizás alguien de MetaQuotes pueda comentar este punto?

En cualquier caso, ¡espero que estés progresando! :)

 
angevoyageur:
¿Cuántos agentes están disponibles cuando se rechazan todos los que tienen menos de 32G de ram?

Hola,

Parece una gran cantidad de RAM para un PC de consumo, pero la nube no parece tener ningún problema para encontrar máquinas con estas especificaciones. Cuando empiezo una optimización, el optimizador encuentra fácilmente los 64 agentes iniciales y luego sube rápidamente a 128 (dependiendo de la configuración del conjunto de parámetros, por supuesto). Inicialmente probé con 8GB - la optimización se ejecutaba durante más tiempo y a menudo se completaba pero todavía tenía regularmente un agente que producía el error y como resultado, mataba la optimización. Luego probé con 16GB - de nuevo, fue mejor pero no impecable. No me molesté en probar con 24GB - pensé en ir directamente a 32GB y ver qué pasaba :) Y voilà - optimizaciones impecables.

Quería jugar mucho más y ver si podía afinar un poco más los requisitos de configuración de los agentes, pero cuando te cobran por jugar, el incentivo desaparece rápidamente. :)

 
cowil:

Hola,

Parece una gran cantidad de RAM para un PC de consumo, pero la nube no parece tener ningún problema para encontrar máquinas con estas especificaciones. Cuando empiezo una optimización, el optimizador encuentra fácilmente los 64 agentes iniciales y luego sube rápidamente a 128 (dependiendo de la configuración del conjunto de parámetros, por supuesto). Inicialmente probé con 8GB - la optimización se ejecutaba durante más tiempo y a menudo se completaba pero todavía tenía regularmente un agente que producía el error y como resultado, mataba la optimización. Luego probé con 16GB - de nuevo, fue mejor pero no impecable. No me molesté en probar con 24GB - pensé en ir directamente a 32GB y ver qué pasaba :) Y voilà - optimizaciones impecables.

Quería jugar mucho más y ver si podía afinar un poco más los requisitos de configuración del agente, pero cuando te cobran por jugar, el incentivo desaparece rápidamente :)

Sería interesante tener algún retorno de Metaquotes. Si una máquina con 16G de ram no es suficiente para ejecutar alguna optimización hay algo que investigar. Si entendí bien, cuando se ejecuta la optimización localmente no se tiene ningún problema, ¿por qué entonces cuando se usa la nube hay necesidad de tanta memoria?
 
angevoyageur:
Sería interesante tener alguna respuesta de Metaquotes. Si una máquina con 16G de ram no es suficiente para ejecutar alguna optimización hay algo que investigar. Si he entendido bien, cuando se ejecuta la optimización localmente no tiene ningún problema, ¿por qué entonces cuando se utiliza la nube hay una necesidad de tanta memoria?

No tengo ni idea. Mi máquina local es una máquina con un procesador i7 de 8 GB, en la que MT5 instaló 8 agentes locales (obviamente es sólo un procesador de 4 núcleos, pero con Hyper-Threading, Windows y por lo tanto MT5 lo ven por supuesto como un procesador de 8 núcleos). Cuando se está llevando a cabo una optimización, los agentes parecen utilizar unos 400 MB de memoria cada uno, lo que obviamente supone unos 3,2 GB de memoria necesaria para los 8 agentes. Ni de lejos 32 GB....

La otra cosa en la que estaba pensando y que podría ser la causa de este problema, es el hecho de que un agente de la nube "malo" termina toda la optimización. Lo que puede estar ocurriendo es que cuando el servidor de la nube asigna agentes para un trabajo de optimización (sin que se indiquen los requisitos de memoria), se seleccionan los mismos agentes "malos". Cuando los requisitos de memoria se indican en OnInit(), los agentes "malos" se omiten porque las cajas en las que se ejecutan no cumplen los requisitos y sólo se seleccionan los agentes buenos. Pensando en ello, sospecho que esto es probablemente más el caso.

Y sí, he registrado este asunto en MetaQuotes pero aún no he recibido respuesta.

 

Si OnInit (o cualquier otra función) se ejecuta durante más de 10 minutos, incluso en un agente lento, se considera un bucle sin fin perjudicial para la red MQL5 Cloud Network (tenga en cuenta que no existe tal limitación para los agentes locales y remotos).

Para este tipo de situaciones, hemos implementado el código de retorno INIT_AGENT_NOT_SUITABLE para la función OnInit. Usándolo, un usuario de la red en la nube puede comprobar y rechazar los agentes no aptos al inicio de la ejecución de una prueba.

Puedes considerar este comentario como una respuesta oficial a tu ticket del Service Desk. Sabemos que conoce la información que se ha dado más arriba.

Además: En cualquier caso, se considera que cualquier función es anormal, ineficaz y no óptima si su ejecución tarda más de 10 minutos incluso en un PC más lento.

 
MetaQuotes:

Si OnInit (o cualquier otra función) se ejecuta durante más de 10 minutos, incluso en un agente lento, se considera un bucle sin fin perjudicial para la red MQL5 Cloud Network (tenga en cuenta que no existe esta limitación para los agentes locales y remotos).

Para este tipo de situaciones, hemos implementado el código de retorno INIT_AGENT_NOT_SUITABLE para la función OnInit. Usándolo, un usuario de la red en la nube puede comprobar y rechazar los agentes no aptos al inicio de la ejecución de una prueba.

Puedes considerar este comentario como una respuesta oficial a tu ticket del Service Desk. Sabemos que conoce la información que se ha dado más arriba.

Además: En cualquier caso, se considera que cualquier función es anormal, ineficaz y no óptima si su ejecución tarda más de 10 minutos incluso en un PC más lento.

Hola MetaQuotes,

En primer lugar, muchas gracias por tus comentarios - muy apreciados.

El problema al que me enfrento (y otros, aparentemente, si miras hacia atrás en este post) es que cuando se lleva a cabo una optimización utilizando mis agentes locales, la optimización se ejecuta bien, es decir, el estado de "porcentaje completado" en cada agente aumenta constantemente a medida que avanza la optimización. Si el manejador de eventos OnTick() en mi Expert contuviera algún código que tardara más de un minuto (por no hablar de 10 minutos) en completarse, seguramente esos porcentajes de "porcentaje completado" se detendrían en esos momentos. ¿No debería ver pausas de 10 minutos (o más) en estos porcentajes de estado si mi código contuviera las formas de bucle interminable a las que aluden los errores del agente de la nube?

 

Bueno, después de muchas horas de reducir mi Experto, parece que he encontrado una/la fuente de los problemas con los errores de "bucle sin fin" de OnInit() o OnTick() - esto es el comando SymbolInfoInteger(). No sé si SymbolInfoDouble() o SymbolInfoTick() causan los mismos problemas ya que todavía no he tenido la oportunidad de experimentar más. Si alguien quiere probar esto, ejecute el siguiente Experto en el Optimizador, utilizando agentes de la nube:

/+------------------------------------------------------------------+
//|                                              MultiSymbolTest.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
input double var1 = 45;
input double var2 = 54;

input bool onInit = true;
input bool onTick = false;


//+------------------------------------------------------------------+
//| expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit() { 

    
    if (onInit) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return(INIT_FAILED);
        }
    }           

    // Return...
    return(INIT_SUCCEEDED);
}



//+------------------------------------------------------------------+
//| expert start function                                            |
//+------------------------------------------------------------------+
void OnTick() {

    if (onTick) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return;
        }
    }           

    ExpertRemove();
}    

Seleccionad si queréis probar OnInit() o OnTick(), dad a var1 y var2 suficientes valores de inicio/paso/parada para generar unas 1000 combinaciones (probablemente menos, pero esto es lo que he estado usando) y disparad el optimizador. En aproximadamente 10 minutos, verás el error "bucle sin fin detectado".

Ah, y la razón por la que puse el "ExpertRemove()" al final de OnTick() fue para mostrar que sólo se necesita una iteración de OnTick() para generar el error.

No hace falta decir que también he informado de esto al servicio técnico...

 
Ah, y me olvidé de mencionar que, por la razón que sea, el arreglo de la memoria que proporcioné arriba parece arreglar el problema la mayoría de las veces, pero no todas. Cómo/por qué/qué funciona esto, no lo sé. Debe hacer cosquillas a algo en las entrañas de MT5... :)
 

Puedo confirmar este problema :

2013.05.20 14:22:31 MQL5 Cloud Europe 2 pase genético (0, 22) probado con el error "bucle sin fin detectado en la función OnInit, experto rechazado por MQL5 Cloud Network" en 602 seg (PR 140)

 
Necesito pensar...
12345
Nuevo comentario