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

[Slava]

O que há de diferente entre 10 minutos e 20 minutos? Não há diferença. 10 minutos é extremamente longo para uma única chamada. Você quer um teste escrito errado EA? Não há problema. Mas não expanda seus problemas no servidor público da Cloud. Outros usuários também querem usar o Cloud server. Você pode usar agentes locais e agentes remotos sem qualquer restrição - Você é bem-vindo.

[Alain Verleyen]

cowil:

Oi Stringo,

Primeiramente, obrigado pela informação.

No entanto, estou interessado no raciocínio da MetaQuotes para isto. Se uma grande quantidade de dados "Every Tick" for utilizada (digamos, por exemplo, 2003.1.1 -> 2013.1.1) e o Perito sendo otimizado for razoavelmente complicado, muitas vezes levará mais de 10 minutos para que uma única iteração de otimização ocorra. Existe alguma razão específica para que a MetaQuotes tenha escolhido um período de 10 minutos como tempo limite? Além disso, há alguma forma de o usuário da nuvem aumentar esse tempo limite ou isso foi "hard wired" pela MetaQuotes?

stringo:
Loop interminável detectado apenas em Agentes de Nuvem. Se uma das chamadas(OnInit, OnDeinit, OnTick, OnTimer, etc.) funcionar mais de 10 minutos

Não é uma otimização única, é uma chamada de sinal para uma função.

[cowil]

angevoyageur:
Não é uma única otimização, é uma chamada de sinal para uma função.

Ah - meu erro - de alguma forma eu tinha na minha cabeça que estávamos falando de uma única iteração de otimização, em vez de uma única chamada para um manipulador de eventos (embora Stringo tivesse mencionado especificamente uma única chamada para um manipulador de eventos). Uma única chamada para um responsável por um evento que dura mais de 10 minutos seria de fato ridículo.Minhas humildes desculpas - deve ter tido um desbotamento cerebral - tempo para descansar o cérebro :)

Mmmmm - então deve haver algo estranho acontecendo dentro do meu Expert que está fazendo com que OnTick() leve ocasionalmente mais de 10 minutos para completar uma chamada. Tempo para começar a cavar...

De qualquer forma, obrigado novamente por sua ajuda, pessoal!

[Slava]

angevoyageur:
Não é uma otimização única, é uma chamada de sinal para uma função.

Exatamente. Uma única chamada não pode ser maior do que 10 minutos em uma de agentes da Nuvem.

[cowil]

Hi,

Ainda cavando, mas lutando para encontrar alguma coisa. O fato de meu especialista otimizar sem falhas meus agentes locais (ou seja, nenhuma das porcentagens de progresso de meus agentes pára ou pára a qualquer momento, o que eu pensaria que seria o caso se houvesse algum tipo de loop infinito em minha função OnTick() que durasse pelo menos 10 minutos ou mais) realmente dificulta a tarefa.

Uma coisa que me interessa - o que o número PR no final da mensagem de erro indica (ou seja, ".... expert rejeitado pela MQL5 Cloud Network em 600 seg.(PR116)". Alguém pode lançar alguma luz sobre isto?

Agradecemos antecipadamente sua ajuda com isto.

[Alain Verleyen]

cowil:

Hi,

Ainda cavando, mas lutando para encontrar alguma coisa. O fato de meu especialista otimizar sem falhas meus agentes locais (ou seja, nenhuma das porcentagens de progresso de meus agentes pára ou pára a qualquer momento, o que eu pensaria que seria o caso se houvesse algum tipo de loop infinito em minha função OnTick() que durasse pelo menos 10 minutos ou mais) realmente dificulta a tarefa.

Uma coisa que me interessa - o que o número PR no final da mensagem de erro indica (ou seja, ".... expert rejeitado pela MQL5 Cloud Network em 600 seg.(PR116)". Alguém pode lançar alguma luz sobre isto?

Agradecemos antecipadamente sua ajuda com isto.

PR é uma classificação de desempenho de um agente calculado de acordo com um método unificado especial. Quanto mais alto for o PR de um agente, mais rápido ele realiza sua tarefa e mais alto é o preço de aluguel por unidade de tempo como resultado.

Veja aqui para mais informações.

[cowil]

angevoyageur:
Veja aqui para mais informações.

Ah - isso certamente explica as coisas. Obrigado por sua ajuda!

[cowil]

Hi,

Bem, depois de passar muitas horas durante o fim de semana examinando meu código, não consegui encontrar nenhum lugar dentro do código do meu Expert onde a possibilidade de um loop infinito pudesse surgir. E no processo, eu também fiquei cada vez mais convencido de que se meu Expert tivesse tido problemas de loop sem fim, eu deveria ter visto isso se tornar aparente ao usar meus agentes locais para otimizar meu Expert. Como mencionei acima, meus agentes locais não param em nenhuma etapa durante uma otimização do meu Expert - muito menos por um período de dez minutos ou mais.

Depois de me convencer que as questões não surgiram do meu Especialista, comecei a examinar as outras alternativas. A única alternativa lógica que pude ver foi que havia problemas com os próprios agentes (ou seja, insetos) ou problemas com as caixas em que eles estavam correndo. Parece que a segunda destas alternativas parece ser a culpada.

Pelo que pude perceber, as pessoas estão correndo com agentes de nuvens em todo tipo de caixas. Também estou presumindo que estes agentes de nuvens são todos baseados no Windows. A razão pela qual menciono isto é que minha própria experiência pessoal das versões de consumo do Windows é que elas são notoriamente instáveis quando são açoitadas por qualquer período de tempo, tendendo a diminuir a velocidade ou até mesmo a se agarrar quando sobrecarregadas com qualquer demanda séria de processamento.

As otimizações que tenho tentado realizar dizem respeito a um Expert razoavelmente complexo sendo executado em 6-7 anos de dados"Every Tick" - ou seja, exigindo processamento e demandas de memória razoáveis. Suspeitei que os agentes na nuvem que estavam assumindo esta tarefa não eram suficientemente específicos - especialmente considerando que eles seriam caixas do Windows.

Portanto, coloquei a seguinte linha de código no meu gerenciador de eventos OnInit():

    // Check optimisation agent stats...
    if (MQL5InfoInteger(MQL5_OPTIMIZATION) && TerminalInfoInteger(TERMINAL_MEMORY_PHYSICAL) < 32000)
        return(INIT_AGENT_NOT_SUITABLE);

A razão pela qual usei TERMINAL_MEMORY_PHYSICAL é que as outras opções de memória:TERMINAL_MEMORY_TOTAL e TERMINAL_MEMORY_AVAILABLE não são muito úteis, pois fornecem apenas o espaço de endereço virtual total em modo usuário do processador do host (ou seja, 4GB para um processador de 32 bits ou 8TB para um processador de 64 bits). Não consigo imaginar nenhuma máquina de 64 bits com 8TB de memória - pelo menos, ainda não. :) TERMINAL_CPU_CORES foi outro que considerei, mas decidi, no final, ir apenas com testes para memória, pois eu assumiria que qualquer caixa com uma quantidade decente de memória seria decentemente espec'ed em todas as outras áreas importantes.

E adivinhe o quê - sem mais problemas! Todas as minhas otimizações agora estão funcionando bem :)

[Clock]

cowil:

Hi,

Bem, depois de passar muitas horas durante o fim de semana examinando meu código, não consegui encontrar nenhum lugar dentro do código do meu Expert onde a possibilidade de um loop infinito pudesse surgir. E no processo, eu também fiquei cada vez mais convencido de que se meu Expert tivesse tido problemas de loop sem fim, eu deveria ter visto isso se tornar aparente ao usar meus agentes locais para otimizar meu Expert. Como mencionei acima, meus agentes locais não param em nenhuma etapa durante uma otimização do meu Expert - muito menos por um período de dez minutos ou mais.

Depois de me convencer que as questões não surgiram do meu Especialista, comecei a examinar as outras alternativas. A única alternativa lógica que pude ver foi que havia problemas com os próprios agentes (ou seja, insetos) ou problemas com as caixas em que eles estavam correndo. Parece que a segunda destas alternativas parece ser a culpada.

Pelo que pude perceber, as pessoas estão correndo com agentes de nuvens em todo tipo de caixas. Também estou presumindo que estes agentes de nuvem são todos baseados no Windows. A razão pela qual menciono isto é que minha própria experiência pessoal das versões de consumo do Windows é que elas são notoriamente instáveis quando são açoitadas por qualquer período de tempo, tendendo a diminuir a velocidade ou até mesmo a se agarrar quando sobrecarregadas com qualquer demanda séria de processamento.

As otimizações que tenho tentado realizar dizem respeito a um Expert razoavelmente complexo sendo executado em 6-7 anos de dados "Every Tick" - ou seja, exigindo processamento e exigências de memória razoáveis. Suspeitei que os agentes na nuvem que estavam assumindo esta tarefa não eram suficientemente específicos - especialmente considerando que eles seriam caixas do Windows.

Portanto, coloquei a seguinte linha de código no meu gerenciador de eventos OnInit():

A razão pela qual usei TERMINAL_MEMORY_PHYSICAL é que as outras opções de memória:TERMINAL_MEMORY_TOTAL e TERMINAL_MEMORY_AVAILABLE não são muito úteis, pois fornecem apenas o espaço de endereço virtual total em modo usuário do processador do host (ou seja, 4GB para um processador de 32 bits ou 8TB para um processador de 64 bits). Não consigo imaginar nenhuma máquina de 64 bits com 8TB de memória - pelo menos, ainda não. :) TERMINAL_CPU_CORES foi outro que considerei, mas decidi, no final, ir apenas com testes para memória, pois eu assumiria que qualquer caixa com uma quantidade decente de memória seria decentemente espec'ed em todas as outras áreas importantes.

E adivinhe só - sem mais problemas! Todas as minhas otimizações agora estão funcionando bem :)

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...

[Alain Verleyen]

cowil:
...

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