MetaTrader 5 Strategy Tester e MQL5 Cloud Network - página 28
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
Obrigado Renat, tenho outra pergunta, talvez em algum lugar sobreposta à pergunta de Andrei, a prioridade do processo metatester.exe é definida para "baixa", o que é basicamente correcto, de modo a não interferir, digamos, na digitação do Word, é possível ou planeia definir a prioridade do utilizador para ser baixa durante o dia, quando as pessoas trabalham, mas à noite é a toda a velocidade?
Na realidade, não é possível controlar absolutamente a carga da CPU quando um agente está em funcionamento.
Mas uma prioridade mais baixa ajuda realmente quando o utilizador está a utilizar o computador para outras tarefas - neste caso, são efectivamente atribuídos menos recursos aos agentes da nuvem (não quando estão a funcionar localmente!). Por outras palavras, pode trabalhar em Wordboards sem demasiados problemas.
Existe também uma tabela de horários para a computação em nuvem, onde se pode especificar o tempo de desconexão da rede. Por exemplo, durante o horário de trabalho das 08:00-17:00, os agentes podem ser desconectados.
Aumentar a prioridade de baixo para alto não faz sentido porque quando não há tarefas de nível superior, todos os recursos irão para processos com menor prioridade. Isto facilita que os agentes assumam automaticamente 100% da CPU.
Renat, por favor informe, tenho dois terminais instalados e dois gestores em funcionamento. O processador tem 4 núcleos e portanto os agentes são 8.
Isto foi feito porque a carga no processador com um gestor a funcionar era insignificante, e com dois, aumentou.
É possível fazê-lo, e não existem conflitos no trabalho de gestores de diferentes terminais e, mais importante ainda, uma fraqueza
em termos de manutenção de estatísticas de trabalho e possível batota de $. Obrigado de antemão.
Estão todos os 8 agentes na rede de nuvens?
Neste caso, é suficiente colocar apenas 4 agentes. A questão é que 8 agentes podem de facto fazer menos tarefas do que 4 agentes. Não esquecer os custos fixos de cada agente (memória, CPU, massa de fios em execução, etc.).
ps: uma pele (computador) pode ser utilizada para coser 4 chapéus (agentes) completos, pode coser 8 ou mesmo 16, com uma degradação correspondente do resultado
Estão todos os 8 agentes na rede de nuvens?
Neste caso, é suficiente colocar apenas 4 agentes. A questão é que 8 agentes podem de facto realizar menos tarefas do que 4 agentes. Não esquecer os custos fixos de cada agente (memória, CPU, massa de fios em execução, etc.).
ps: a partir de uma pele (computador) pode fazer 4 chapéus (agentes) completos, e pode fazer 8 ou mesmo 16 com a degradação correspondente do resultado
Não me cabe a mim confirmar as palavras de um profissional, mas sei isto pela prática, é a mais pura verdade, é por isso que a classificação dos agentes era necessária.
Eu costumava gerir 24 agentes numa máquina de núcleo duplo, é verdade que eles sufocam, melhor um agente por núcleo. Mesmo 2 agentes por núcleo é um pouco mais lento.
Há muito tempo que não tenho acesso ao MT5. Mas eu refiz tudo na mesma, eu refiz a coruja. Executar a optimização e ver que os agentes das nuvens estão a carregar a história de anos muito distantes (1990, por exemplo). A optimização está a ser feita para o último mês. Então porque é que os agentes estão a descarregar tanta história?
Ao iniciar um teste em qualquer secção temporal, o terminal verifica e sincroniza necessariamente o histórico disponível a partir do servidor. Isto é feito devido ao facto de que quase qualquer comerciante, mais cedo ou mais tarde, solicitará todo o historial disponível para testes.
O terminal dará o histórico aos agentes no montante solicitado, mas não toda a profundidade disponível. Além disso, em 99% dos casos, o histórico de muitos corretores já está armazenado em servidores geograficamente distribuídos da MQL5 Cloud Network, e a partir deles é entregue/sincronizado aos agentes.
Os agentes remotos também mantêm enormes caches de dados históricos para diferentes corretores, o que lhes permite passar instantaneamente a fase de sincronização sem descarregar o histórico.
Fizemos um sistema de computação distribuída muito eficiente e rentável. Para estimar a quantidade de dados transferidos durante a sincronização, olhar para os registos dos agentes (não no terminal, mas exactamente para os agentes nos ficheiros de registo).
Não posso iniciar um agente no trabalho na coluna com tráfego de entrada/saída é teimosamente 0kb e não aparece na lista de agentes no website.
A Internet está a funcionar através de firewall no linux.
Escreveu no primeiro post que, graças ao SSL, pode atravessar quaisquer firewalls.
Talvez deva especificar algumas definições de proxy e autorização no mesmo?
ou abrir algumas portas na firewall?
s.e. tudo funciona bem em casa
aconselhar Renat
Não posso iniciar um agente no trabalho na coluna com tráfego de entrada/saída é teimosamente 0kb e não aparece na lista de agentes no website.
A Internet está a funcionar através de firewall no linux.
Escreveu no primeiro post que, graças ao SSL, pode atravessar quaisquer firewalls.
Talvez deva especificar nele algumas definições de proxy e autorização?
ou talvez deva abrir algumas portas na firewall?
s.e. tudo funciona bem em casa
Olá! Surgiram resultados interessantes...
Olá! Surgiram resultados interessantes...
está tudo a funcionar! Obrigado!
A abertura, na firewall Linux, dos limiares 2000-2001 para a gama de endereços 1 a 5.agents.mql5.com ajudou.