Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Os resultados dos passes não correspondem à optimização e ao passe único (service-desk - #329165 + EA no mesmo local)
Os resultados da optimização e do passe único não coincidem (service-desk - #329165 + EA também lá)
Construir 619? O mesmo problema começou a ocorrer. Mas nem sempre. Por vezes os resultados são mesmo os mesmos, ou seja, não realizei nenhuma nova optimização, mas ao testar, obtenho resultados diferentes por alguma razão. Por exemplo, o lucro final no gráfico difere do que consta da lista. Após algum tempo, tudo é restaurado. Nunca tinha reparado nisto antes de construir 619 .
A construção é ainda 607 (ainda não foi actualizada para a nova FIBO). Talvez o problema seja a moeda múltipla e o temporizador (OnTick() não é utilizado), mas não tem a certeza.
Algo está errado com a última construção do testador de estratégia. De repente (não "de repente", mas após a actualização da construção 619) o Expert Advisor parou praticamente de testar (o mesmo que na aplicação #329165) - começou a consumir imensamente memória (o modo "Todos os tiquetaques" durante 5 anos):
A última coluna é "tamanho VM". Como podem ver, tenho 4 núcleos + 4 agentes locais "remotos" (sempre funcionou bem).
Ao mesmo tempo, o sistema começa muito mal (yup, 4GB RAM + 16GB dedicados para PageFile) e a velocidade de optimização tende para o infinito. Como se pode ver, o tempo de CPU, praticamente não está ligado.
Ao mesmo tempo, há erros no registo:
Isto é aparentemente devido à falta de memória.
Carrego em "stop" - a memória não é libertada imediatamente. Em 5 minutos os agentes locais desapareceram, em mais dois minutos, a memória dos agentes remotos foi libertada:
Só não é claro porque é que um agente ainda tem mais de 100Mb pendurados (não acredito que tenha levado o Cloud - porque o tempo de CPU não é utilizado).
Bem, eu desabilito os agentes locais "remotos". Nada muda (atrasos e erros do sistema).
Bem, penso eu, o erro está no meu Conselheiro Especialista. Por conseguinte, começo a testar um ExpertMACD padrão, EURUSD, h12 de 2007.09.01 a 2012.03.26.
И... A mesma imagem - atrasos, utilização de memória louca (quase os mesmos valores que na primeira imagem) + "não pode inicializar o perito".
Em ambos os casos, alguns passes são no entanto bem sucedidos.
Registo em anexo.
Linhas muito interessantes:
etc. com USDNOK - no meu EA um símbolo SGDJPY foi cosido no código - porquê descarregar USDNOK (USDJPY foi carregado com sucesso de acordo com os registos), em vez de USDSGD?
Se alguma coisa, o servidor é o servidor FIBOGroup-MT5.
P. S. Não vi tais problemas em construções anteriores.
P. P. S. Por favor, verifique a optimização do ExpertMACD padrão durante os últimos 5 anos em todos os carrapatos.
Algo está errado com a última construção do testador de estratégia. De repente (não "de repente", mas após actualização para construir 619) a EA praticamente parou os testes (o mesmo que na aplicação #329165) - a memória começa a consumir uma enorme quantidade (o modo "Todas as carraças" durante 5 anos):
A última coluna é "tamanho VM". Como podem ver, tenho 4 núcleos + 4 agentes locais "remotos" (sempre funcionou bem).O sistema começa a abrandar muito horrivelmente (yup, 4GB de RAM + 16GB dados para PageFile) e a velocidade de optimização tende ao infinito. Como se pode ver, o tempo de CPU, praticamente não está ligado.
Não se recomenda a utilização de mais agentes do que os núcleos. O número excessivo de agentes faz com que a velocidade diminua não linearmente e que o consumo de recursos aumente. Especialmente quando há apenas 4 Gb de memória e os agentes consomem um gigabyte ou mais.
Não instalar agentes remotos no mesmo computador onde se trabalha com o terminal.
Existem erros no registo:
Deve ser devido à falta de memória.
Carrego em "stop" - a memória não é libertada de imediato. Em 5 minutos os agentes locais desapareceram, em mais dois minutos a memória remota é libertada:
Sim, a memória (caches) é libertada após cerca de 5 minutos. São mantidos propositadamente para a corrida seguinte, para que o tempo não seja desperdiçado aquecendo na maioria das vezes os mesmos dados que foram utilizados na última corrida.
Na última construção, mudámos a forma como lidamos com as caches, o que as aumentou para acelerar as repetições.
Só não é claro porque é que um agente tem mais de 100Mb pendurados (não acredito que tenha sido utilizado pelo Cloud, porque o tempo de CPU não é utilizado).
Bem, eu desabilito os agentes locais "remotos". Nada muda (atrasos e erros do sistema).
Bem, penso eu, o erro está no meu Conselheiro Especialista. Por conseguinte, estou a testar um padrão ExpertMACD, EURUSD, h12 de 2007.09.01 a 2012.03.26.
Já recompilou o Consultor Especialista após a actualização para a última construção?
No seu caso, o problema está em desaceleração devido à constante troca e falta de memória. Conselhos: Desactivar agentes remotos desnecessários.
Não se recomenda a utilização de mais agentes do que os núcleos. O número excessivo de agentes faz com que a velocidade diminua não linearmente e que o consumo de recursos aumente. Especialmente quando há apenas 4 Gb de memória e os agentes estão a comer um gigabyte ou mais.
Não instale agentes remotos no mesmo computador onde faz o seu trabalho principal com o terminal.
Recompilou a EA após a actualização para a última construção?
No seu caso, o problema está em desaceleração devido à constante troca e falta de memória.
Uma palavra de conselho: desactivar agentes remotos desnecessários.
Eu desabilitei-o, executei o ExpertMACD para optimização e:
E agora todos os agentes (incluindo os agentes locais), excepto um, estão incapacitados:
e agora o quê? 4GB não é suficiente para um agente? (embora o Mem Usage tenha 350MB, tamanho VM = 1,24GB). E quanto àqueles que nem sequer têm 4GB?
Porque não verifica? Ver post anterior para passos de repetição.
Pode olhar para as estatísticas da Cloud - 4 ou 8 agentes - PR ainda está na região de 150-190 (excepto um/dois, que aparentemente caem no núcleo do navegador) Agentes remotos deficientes... Peritos recompilados. Até o ExpertMACD regular recompilado.
Desconectado, geriu o ExpertMACD para optimização e:
Agora, todos os agentes (incluindo os agentes locais) estão incapacitados, excepto um:
e agora o quê? 4GB não é suficiente para um agente? (embora o Mem Usage tenha 350MB, tamanho VM = 1,24GB).
Porque não o verifica afinal? Os passos de reprodução estão no post anterior
Bastava olhar para o diário de bordo da EA para ver os erros:
Escolher o período de tempo correcto e as definições correctas. Se utilizar limites por defeito, pode gerar muitas configurações erradas.
Bastava olhar para o registo da EA para ver os erros:
Escolher o período de tempo certo e as definições certas. Se utilizar limites por defeito, pode gerar muitas configurações erradas.
Sim, de facto, o problema acabou por estar nos parâmetros por defeito. Mudei-os - tudo está a testar bem. Regressei ao meu Conselheiro Especialista - até agora parece estar "a voar normalmente".
Assim, se antes a disponibilidade de dois agentes por núcleo era perdoada, agora definitivamente não o é.
Conclusão2. Estava errado, desculpem o tempo demorado (mas o balcão de atendimento - #329165 ainda não o descobriu)
Havemos de o descobrir.
Está a demorar muito tempo. Entretanto, descobri o que está errado.
1) Ao refacturar o código, perdi a atribuição explícita do valor da variável e por vezes (bastante aleatoriamente) recebi resultados aleatórios para o volume da posição aberta. Tendo corrigido este erro, vi que os resultados não mudaram - os resultados dos testes não coincidiram com a optimização. Vários truques de abate de árvores e pandeiros ajudaram-nos a descobrir que o problema é bastante antigo:
2) Antes do início do Campeonato-2011, informei que o provador faz acordos aos fins-de-semana. Renat prometeu verificá-lo. Mas o problema permanece até aos dias de hoje. Completamente por acidente, escolhi o início do intervalo de testes 2007.09.01, que é um fim-de-semana. Assim, o optimizador não efectua uma troca neste dia, mas o testador sim. Para ser mais preciso, não chega a OrderSend no optimizador ao fim-de-semana, mas chega no testador. A julgar pela lógica do meu consultor especializado, consegui descobrir que se o período de optimização começa no fim-de-semana, ACCOUNT_EQUITY = 0 quando o temporizador dispara pela primeira vez!!! No testador, ACCOUNT_EQUITY = ACCOUNT_BALANCE (é o que estabelecemos no depósito inicial). Se o início do período de optimização cai num dia útil, então o comportamento do optimizador e do testador são idênticos.
Portanto, tem dois bugs:
1) O optimizador permite-lhe abrir um negócio num fim-de-semana, que não deve ser (e não diga que este é o meu erro - corrigirei os meus erros, enquanto o bug do testador estiver pendurado há mais de meio ano);
2) Quando o temporizador dispara pela primeira vez, se o início do período cai na saída, ACCOUNT_EQUITY = 0, enquanto no testador ACCOUNT_EQUITY = ACCOUNT_BALANCE. Temos de o levar à mesma forma (melhor, claro, para ACCOUNT_EQUITY = ACCOUNT_BALANCE com correcção do primeiro erro).
No balcão de atendimento a pedido #329165, anexarei um perito para testes.