Erros de sincronização de nuvens - página 3

Novo comentário
 
Clock:

Isto parece uma grande idéia e estou grato por essa dica.

No entanto, três coisas a respeito disso:

1) Como mencionei acima, também tenho o problema do "loop infinito", mas como entendi deste fio que "loop infinito" é apenas o melhor palpite para "um evento demorou mais de dez minutos", aceito que possa ser meu código. Eu uso indicadores bastante complexos, e como (pelo menos eu acho que sim) eles calculam toda a sua história quando o seu cabo está sendo criado, isto pode (em computadores lentos) demorar mais de dez minutos.

2) No entanto! Normalmente, minha nuvem caiu após 10-15 minutos. Mas ontem à noite, funcionou perfeitamente por 8 horas. Não houve um único travamento, embora eu não tenha mudado o código em absoluto. Estranho!

3) E o mais importante, porque relacionado à sua abordagem: Quando você rejeita um agente com base na sua memória, o agente (e para isso toda a nuvem) não trava, eu entendo isso. Mas eu não acho, que uma máquina mais poderosa tentará o mesmo parâmetro-definido novamente, então você basicamente perde pontos de dados de otimização, estou correto? Você diria, este é o preço que teremos que pagar?


Ficará curioso para ver, se meus agentes ainda trabalham quando eu voltar do trabalho...

Olá Relógio,

1) Primeiramente, a menos que você esteja usando os Indicadores, digamos, 10 anos de dados de 1 milhão e os Indicadores sejam incrivelmente complexos, eu ficaria muito surpreso neste dia e idade de poder de processamento que qualquer coisa levaria até 5 minutos em um sistema NORMAL. A razão pela qual eu sublinho normal aqui é que eu ainda suspeito que há uma série de agentes na nuvem que estão funcionando em máquinas que ou estão extremamente carregadas ou simplesmente têm um caso ruim do Windows (stress pós-traumático) desacelerando o blues. E só é preciso um agente para matar sua otimização....

2) Eu tinha exatamente o mesmo que você - ou seja, depois que uma otimização fosse iniciada, alguns agentes da nuvem retornariam os resultados sem nenhum problema. Então, após 5-20 minutos ou um pouco mais de tempo, às vezes, um agente jogava o temido erro e BANG - o fim da otimização. E eu também tinha a ocasional otimização onde ela terminava sem problemas. MUITO frustrante porque você não tem nenhum acesso aos arquivos de registro dos agentes, detalhes do sistema, uso da CPU, etc., para poder ver o que está acontecendo.

3) Esse é um ponto muito interessante que você faz. Do meu entendimento das coisas, o otimizador só considera uma combinação particular de parâmetros "usados" quando tem os resultados para essa combinação particular de parâmetros, embora eu possa estar errado com isso. Talvez alguém da MetaQuotes possa comentar sobre este ponto?

De qualquer forma, espero que você esteja fazendo progressos! :)

 
angevoyageur:
Quantos agentes estão disponíveis quando você rejeita todos aqueles com menos de 32G de carneiro?

Hi,

Parece uma grande quantidade de RAM para PCs do tipo consumidor, mas a nuvem não parece ter nenhum problema em encontrar máquinas com estas especificações. Quando inicio uma otimização, o otimizador encontra facilmente os 64 agentes iniciais e depois sobe muito rapidamente para 128 (dependendo da configuração do conjunto de parâmetros, é claro). Inicialmente tentei 8GB - a otimização funcionou por mais tempo e muitas vezes foi concluída, mas ainda tinha regularmente um agente que produzia o erro e, como resultado, matava a otimização. Tentei então 16GB - novamente, foi melhor, mas não impecável. Não me preocupei em tentar 24GB - pensei em ir direto para 32GB e ver o que acontecia :) E voilà - otimizações impecáveis.

Eu queria brincar muito mais e ver se eu poderia melhorar um pouco os requisitos de configuração do agente, mas quando se está sendo cobrado por brincar, o incentivo desaparece rapidamente :)

 
cowil:

Hi,

Parece uma grande quantidade de RAM para PCs do tipo consumidor, mas a nuvem não parece ter nenhum problema em encontrar máquinas com estas especificações. Quando inicio uma otimização, o otimizador encontra facilmente os 64 agentes iniciais e depois sobe muito rapidamente para 128 (dependendo da configuração do conjunto de parâmetros, é claro). Inicialmente tentei 8GB - a otimização funcionou por mais tempo e muitas vezes foi concluída, mas ainda tinha regularmente um agente que produzia o erro e, como resultado, matava a otimização. Tentei então 16GB - novamente, foi melhor, mas não impecável. Não me preocupei em tentar 24GB - pensei em ir direto para 32GB e ver o que acontecia :) E voilà - otimizações impecáveis.

Eu queria brincar muito mais e ver se eu poderia melhorar um pouco os requisitos de configuração do agente, mas quando se está sendo cobrado por brincar, o incentivo desaparece rapidamente :)

Seria interessante ter algum retorno de Metaquotes. Se uma máquina com cilindro de 16G não é suficiente para executar alguma otimização, há algo a investigar. Se eu entendi bem, quando você executa sua otimização localmente você não tem nenhum problema, por que então ao usar a nuvem há uma necessidade de tanta memória?
 
angevoyageur:
Seria interessante ter algum retorno da MetaQuotes. Se uma máquina com cilindro de 16G não é suficiente para executar alguma otimização, há algo a investigar. Se eu entendi bem, quando você executa sua otimização localmente você não tem nenhum problema, por que então ao usar a nuvem há uma necessidade de tanta memória?

Não tenho a menor idéia. Minha máquina local é uma máquina processadora i7 de 8GB, na qual o MT5 instalou 8 agentes locais (obviamente é apenas um processador de 4 núcleos, mas com Hyper-Threading, Windows e, portanto, o MT5 a vê, naturalmente, como um processador de 8 núcleos). Quando uma otimização está sendo realizada, os agentes parecem utilizar cerca de 400MB de memória cada um, o que obviamente funciona com cerca de 3,2 GB de memória necessária para os 8 agentes. Em nenhum momento perto de 32 GB....

A outra coisa em que eu estava pensando, que poderia ser a causa principal desta questão, é o fato de que um "mau" agente de nuvem termina toda a otimização. O que pode estar de fato acontecendo é que quando o servidor da nuvem aloca agentes para um trabalho de otimização (sem que os requisitos de memória sejam indicados), o(s) mesmo(s) agente(s) "ruim(s)" é(são) selecionado(s). Quando os requisitos de memória são declarados no OnInit(), os "maus" agentes são contornados porque as caixas nas quais eles estão rodando não atendem aos requisitos e somente os bons agentes são selecionados. Pensando nisso, suspeito que este seja provavelmente mais o caso.

E sim, registrei esta questão na MetaQuotes, mas ainda não ouvi nada de volta.

 

Se o OnInit (ou qualquer outra função) for executado por mais de 10 minutos mesmo em um agente lento, é considerado como um loop infinito prejudicial para a MQL5 Cloud Network (Note que não há tal limitação para os agentes locais e remotos).

Para este tipo de situações, implementamos o código de retorno INIT_AGENT_NOT_SUITABLE para a função OnInit. Usando-o, um usuário da rede de nuvem pode verificar e rejeitar agentes inadequados logo no início de uma execução de teste.

Você pode considerar este comentário como uma resposta oficial ao seu ticket do Service Desk. Sabemos que você está familiarizado com as informações fornecidas acima.

Além disso: Em qualquer caso, qualquer função é considerada anormal, ineficaz e não otimizada se sua execução leva mais de 10 minutos, mesmo em um PC mais lento.

 
MetaQuotes:

Se o OnInit (ou qualquer outra função) for executado por mais de 10 minutos mesmo em um agente lento, é considerado como um loop infinito prejudicial para a MQL5 Cloud Network (Note que não há tal limitação para os agentes locais e remotos).

Para este tipo de situações, implementamos o código de retorno INIT_AGENT_NOT_SUITABLE para a função OnInit. Usando-o, um usuário da rede de nuvem pode verificar e rejeitar agentes inadequados logo no início de uma execução de teste.

Você pode considerar este comentário como uma resposta oficial ao seu ticket do Service Desk. Sabemos que você está familiarizado com as informações fornecidas acima.

Além disso: Em qualquer caso, qualquer função é considerada anormal, ineficaz e não otimizada se sua execução leva mais de 10 minutos, mesmo em um PC mais lento.

Olá MetaCotações,

Primeiramente, muito obrigado por seus comentários - muito apreciado.

O problema que eu enfrento (e outros aparentemente se você olhar para trás neste post) é que quando uma otimização é realizada usando meus agentes locais, a otimização corre bem - ou seja, o status de "porcentagem completa" em cada agente aumenta constantemente à medida que a otimização avança. Se o manipulador de eventos OnTick() em meu Expert contivesse qualquer código que levasse mais de um minuto (quanto mais 10 minutos) para ser completado, certamente essas porcentagens de "porcentagem completa" fariam uma pausa nesses momentos? Não deveria eu estar vendo pausas de 10 minutos (ou mais) nestas porcentagens de status se meu código contivesse as formas de looping sem fim a que os erros do agente da nuvem fazem alusão?

 

Bem, depois de muitas horas de trabalho com o meu Expert, parece que encontrei a fonte dos problemas com o OnInit() ou OnTick() erros de "loop infinito" - sendo este o comando SymbolInfoInteger(). Eu não sei se SymbolInfoDouble() ou SymbolInfoTick() causam os mesmos problemas que eu ainda não tive a chance de experimentar mais. Se alguém quiser experimentar isto, execute o seguinte Expert in the Optimiser, usando agentes de nuvem:

/+------------------------------------------------------------------+
//|                                              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();
}    

Selecione se você quer testar OnInit() ou OnTick(), dê à var1 e var2 valores de início/passo suficientes para gerar cerca de 1000 combinações (provavelmente menos, mas isto é o que tenho usado) e acione o Otimizador. Em aproximadamente 10 minutos, você verá o erro "loop infinito detectado".

Ah, e a razão pela qual coloquei o "ExpertRemove()" no final de OnTick() foi para mostrar que basta apenas uma iteração de OnTick() para gerar o erro.

Escusado será dizer que também informei isto à central de serviço.

 
Ah, e esqueci de mencionar que por qualquer razão, a correção da memória que forneci acima parece resolver o problema na maioria das vezes, mas não em todos. Como/porquê/que funciona, não sei. Deve fazer cócegas em algo nas entranhas do MT5... :)
 

Posso confirmar esta questão :

2013.05.20 14:22:31 MQL5 Cloud Europe 2 genetic pass (0, 22) testado com erro "loop interminável detectado na função OnInit, especialista rejeitado pela MQL5 Cloud Network" em 602 seg (PR 140)

 
Necessidade de pensar...
12345
Novo comentário
Razão: