Milagres com o provador. - página 3

Novo comentário
 
notused:
Os resultados dos passes não correspondem à optimização e ao passe único (service-desk - #329165 + EA no mesmo local)
Vamos descobrir.
 
notused:
Os resultados da optimização e do passe único não coincidem (service-desk - #329165 + EA também lá)
Construir 619? Este problema também começou a ocorrer. Mas nem sempre. Por vezes os resultados são mesmo os mesmos, ou seja, não foi feita nenhuma nova optimização, mas os resultados dos testes são de alguma forma diferentes. 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 .
 
tol64:
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 .
O edifício 607 (ainda não foi actualizado para a nova FIBO). Talvez o problema esteja em múltiplas moedas e temporizador (OnTick() não é utilizado), mas não tem a certeza.
 
notused:
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.
Depois o nome do ramo é escolhido com precisão. Milagres com o provador. )))
 

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:

CJ      0       local4  17:42:32        USDNOK: history synchronization started
QL      0       Core 1  17:42:33        USDNOK: history synchronization started
RK      0       local4  17:43:49        USDNOK: history downloading completed
GL      0       Core 1  17:43:49        USDNOK: history downloading completed
NM      0       Core 1  17:43:49        USDNOK: history for 2006 year synchronized
QJ      0       local4  17:43:49        USDNOK: history for 2006 year synchronized

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.

Arquivos anexados:
20120326.log  33 kb
 
notused:

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.

 
Renat:

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.

Pode ver as estatísticas do Cloud - quer sejam 4 ou 8 agentes - o PR ainda ronda os 150-190 (excepto um/dois, que aparentemente caem no núcleo do navegador)
Renat:

Não instale agentes remotos no mesmo computador onde faz o seu trabalho principal com o terminal.

Agentes remotos incapacitados...
Renat:

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.

Peritos recompilados. Até o ExpertMACD regular recompilado.
Renat:

Uma palavra de conselho: desactivar agentes remotos desnecessários.

Eu desabilitei-o, executei o ExpertMACD para optimização e:

GS      2       Core 2  22:35:03        genetic pass (14, 128209952076) tested with error "cannot initialize expert"
JD      2       Core 2  22:35:47        genetic pass (18, 83657327618) tested with error "cannot initialize expert"
HK      2       Core 1  22:35:55        genetic pass (21, 125407780989) tested with error "cannot initialize expert"
PN      2       Core 2  22:36:31        genetic pass (23, 119213797642) tested with error "cannot initialize expert"
DQ      2       Core 2  22:36:31        genetic pass (24, 69556992446) tested with error "cannot initialize expert"
PE      2       Core 3  22:36:35        genetic pass (27, 43810326828) tested with error "cannot initialize expert"
EI      2       Core 3  22:37:15        genetic pass (31, 50607133818) tested with error "cannot initialize expert"
MM      2       Core 3  22:37:15        genetic pass (33, 154340017542) tested with error "cannot initialize expert"
OR      2       Core 3  22:38:10        genetic pass (39, 72154186657) tested with error "cannot initialize expert"
RE      2       Core 3  22:38:53        genetic pass (44, 3365963874) tested with error "cannot initialize expert"
NJ      2       Core 3  22:38:53        genetic pass (45, 69101442583) tested with error "cannot initialize expert"
JO      2       Core 3  22:38:53        genetic pass (46, 13607620667) tested with error "cannot initialize expert"
JS      2       Core 1  22:40:24        genetic pass (53, 86662534982) tested with error "cannot initialize expert"
ID      2       Core 1  22:40:24        genetic pass (54, 101351711755) tested with error "cannot initialize expert"
HG      2       Core 1  22:40:24        genetic pass (55, 121960550013) tested with error "cannot initialize expert"

E agora todos os agentes (incluindo os agentes locais), excepto um, estão incapacitados:

IR      2       Core 1  22:44:22        genetic pass (1, 59037561933) tested with error "cannot initialize expert"
GE      2       Core 1  22:44:56        genetic pass (3, 122174849602) tested with error "cannot initialize expert"

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.

 
notused:
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:

ExpertMACD (EURUSD,H1)  22:50:54        1971.01.05 00:00:00   CExpertBase::InitHigh: error initializing object
ExpertMACD (EURUSD,H1)  22:50:54        1971.01.05 00:00:00   OnInit: error initializing indicators

ExpertMACD (EURUSD,H1)	22:55:07	2012.01.01 00:00:00   CSignalMACD::ValidationSettings: slow period must be greater than fast period
ExpertMACD (EURUSD,H1)	22:55:07	2012.01.01 00:00:00   OnInit: error signal parameters

Escolher o período de tempo correcto e as definições correctas. Se utilizar limites por defeito, pode gerar muitas configurações erradas.

 
Renat:

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)

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

1234567
Novo comentário
Razão: