MetaTrader 5 Strategy Tester e MQL5 Cloud Network - página 30
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
Receio que com 24 agentes em 8 núcleos (4 essencialmente + hypertrading) irá gastar todo o desempenho do CPU no fornecimento de infra-estruturas.
A exposição de um número excessivo de agentes faz com que o seu índice de desempenho de RP caia drasticamente, resultando num múltiplo da taxa.
Há já algum tempo que não utilizo a nuvem. Decidiu utilizá-lo na selecção dos parâmetros. O trabalho da nuvem foi agradavelmente surpreendente.
Se se moer um sistema de rede distribuída durante muito tempo, obtém-se um bom resultado.
No total, não há hipótese de ser uma hora e meia.
P. S. Virava a nuvem sobre a mosca. Devido à perda da Internet, os agentes remotos desistiram. Depois não quiseram ligar-se (estado autorizado; pelo menos duas gerações genéticas não se ligaram) - aparentemente, o testador decidiu que há o suficiente para fazer na nuvem, e deixar os agentes livres descansar. Desligou a nuvem. Os agentes remotos estão ligados. Voltou a ligar a nuvem. Acabou com um desligamento.
A rede precisa de ser um pouco finalizada para evitar tais situações (por exemplo, para lembrar o tempo máximo de passagem e se esperar pela passagem durar 2 vezes mais do que o tempo máximo de passagem - para iniciar o mesmo processo no melhor núcleo a partir do local (ou remoto)).
+ TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) precisa de ser refinado
+ a velocidade da genética depende da velocidade do núcleo mais fraco - se os meus núcleos tiverem PR - 160-180, e as tarefas na nuvem são distribuídas por núcleos até 100. Como resultado, em cada geração, os meus núcleos têm de ficar ociosos durante um período de tempo significativo e esperar por respostas da nuvem para gerar uma nova população. Penso que deveria baixar o limite de 100PR e dar prioridade aos agentes que têm um PR superior ao PR do núcleo local mais fraco (+ou núcleo remoto, se ligado). Caso contrário, o equilíbrio de carga deve ser feito de alguma forma. Por exemplo, se assumirmos que todos os passes correm no mesmo núcleo à mesma velocidade (na vida, claro, não é assim, mas muitos peritos com alguns pressupostos, podem ser chamados de estáveis no tempo de teste, independentemente dos parâmetros). Se PR do núcleo local é 150 e PR do núcleo na nuvem é 100, então o agente local deve receber 1,5 vezes mais tarefas do que o agente na nuvem. Alternativamente, se a RP for inferior, não dê aos agentes na nuvem uma tarefa de cada vez, mas dê uma tarefa a uma gama mais vasta de agentes. Neste caso, o tempo de paragem seria mínimo. Em geral, gostaria de ver progressos sobre esta questão
Nas últimas 12 horas, a rede desligou mais três vezes :(
(E há agentes com PR < 100 em revistas de genética)
A propósito, alguém tentou partilhar agentes num ssd? Considerando a forma como o meu disco começa a esmagar em 8 agentes, mesmo sem tarefas, tenho a suspeita de que o recurso ssd está a esgotar-se rapidamente. E ao testar uma EA razoavelmente leve, calcular a velocidade, a velocidade do disco rígido começa a ficar atolada. Quantos terabytes são bombeados para a cache é uma boa pergunta)
Existe tal letra no alfabeto (quero dizer ssd), mas ainda não fiz testes específicos: como o servidor com tal dispositivo está no outro extremo da cidade. Mas, IMHO, em qualquer sistema existe uma cache de disco, que suaviza o acesso frequente ao disco.
Decidi optimizar uma grelha simples (temporizador 30 seg, novo controlo de barras m1) em todas as carraças durante dois pares. Os meus 4 núcleos i5 (PR=160-170) e 8 núcleos i7 (PR=170-180) optimizados para cerca de 90 (!) horas.
Depois verificou-se que as passagens i5 são testadas 2 vezes mais lentamente (embora, como já escrevi várias vezes antes, fosse vice versa - i5 + winxp64 era mais rápido que i7 + win7x64). No início cortei a memória - i7 tem mais do que isso.
Depois olhei acidentalmente para o gestor de tarefas e vi que os agentes têm a prioridade mais baixa (Baixo). E eu tenho-o em ambas as máquinas. E embora tenha conseguido elevar a prioridade à Normal em win7, winxp64bit não o permite por alguma razão. Durante meio dia com novas prioridades na i7, o meu tempo de teste foi reduzido (aparentemente :)) em várias horas.
Tais "desfasamentos" parecem ser observados nas duas últimas construções (ou talvez só me pareça a mim).
E Priority Low é demasiado cruel - se o equipamento pelo menos 12 horas por dia puder dar a máxima prioridade aos agentes.
Em geral, pensei que a prioridade de alguma forma muda automaticamente em função da carga de recursos, mas parece que não muda por si só :(