Minha abordagem. O núcleo é o motor. - página 147
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
Em geral, o problema está quase resolvido.
Estou confuso com o fato de que, digamos 5 EAs estarão transmitindo a quantidade total de pacotes de trabalho se o motor estiver funcionando com um sexto. Os outros cinco devem ser proibidos de transmitir informações de trabalho por enquanto. Deixe-os apenas "ouvir as ondas do ar".
Eu concordo. Isto faz sentido.
Portanto, eles trabalharão normalmente, mas não escreverão mensagens para o recurso. Somente para uma cópia do kernel do parâmetro. E quando conectado, irá escrever o parâmetro kernel no recurso e o Motor irá carregá-lo. Uma vez conectado, o Expert Advisor começará a escrever mensagens para o Motor para o recurso de mensagens.
A questão é sobre a conexão.
O motor expõe um pequeno endereço de fio a todos os EAs. O núcleo da EA com o mesmo endereço de reconhecimento é lembrado e a operação padrão do motor é iniciada automaticamente. Quando o motor muda para outro EA, o motor muda o núcleo do EA com o qual estava trabalhando para o estado de espera do endereço, assim como os outros EAs naquele momento. Neste ponto, todos os EAs estão desligados e o motor está aguardando o outro endereço do EA que o motor precisa.
O núcleo do novo EA responde e entra no estado de operação padrão. A próxima vez que o motor continuar a enviar a linha de chegada e o estado de espera não for alterado. Além da troca padrão, o consultor especializado tem que analisar um fluxo para verificar se o fim da linha de trabalho aparece nela. No início dos pacotes de troca deve haver um fio, indicando a quem um pacote é endereçado a partir do motor. Esse kernel recebe pacotes de controle e começa a enviar pacotes de seu estado com freqüência especificada.
Os outros esperam que eles sejam tratados através de uma cadeia de identificação única para cada EA. Ao trocar, o motor envia à EA atual uma cadeia de fim de vida útil. A EA deixa de enviar qualquer coisa e entra no estado de reconhecer sua própria cadeia de reconhecimento, que é ao mesmo tempo o início do trabalho padrão de troca com o motor.
A questão é sobre a conexão.
O motor expõe um pequeno endereço de fio a todos os EAs. O núcleo da EA com o mesmo endereço de reconhecimento é lembrado e a operação padrão do motor é iniciada automaticamente. Quando o motor muda para outro EA, o motor muda o núcleo do EA com o qual estava trabalhando para o estado de espera do endereço, assim como os outros EAs naquele momento. Neste ponto, todos os EAs estão desconectados e o motor está esperando o outro endereço do EA que o motor precisa.
O núcleo do novo EA responde e entra no estado de operação padrão. A próxima vez que o motor continuar a enviar a linha de chegada e o estado de espera não for alterado. Além da troca padrão, o consultor especializado tem que analisar um fluxo para verificar se o fim da linha de trabalho aparece nela. No início dos pacotes de troca deve haver um fio, indicando a quem um pacote é endereçado a partir do motor. Esse kernel recebe pacotes de controle e começa a enviar pacotes de seu estado com freqüência especificada.
Os outros esperam que eles sejam tratados através de uma cadeia de identificação única para cada EA. Ao trocar, o motor envia à EA atual uma cadeia de fim de vida útil. A EA deixa de enviar qualquer coisa e entra no estado de reconhecer sua própria cadeia de reconhecimento, que é ao mesmo tempo o início do trabalho padrão de troca com o motor.
Os recursos são um pouco mais simples. Você não precisa de um endereço, apenas de um nome de recurso. Você tem um modelo mais complicado. É mais simples.
O núcleo é simplesmente um conjunto de valores. Cada consultor especializado escreverá nele os valores dos parâmetros de seus elementos GUI. Quando necessário, o EAs salvará uma cópia dos parâmetros do kernel para o recurso e o motor o lerá e redesenhará a GUI.
Em princípio, esta é uma tarefa simples, mas há muitas pequenas nuances. Por exemplo, as mensagens sobre iniciar e interromper a comunicação com a EA. Só precisamos pensar no formato.
A propósito, eu consegui acelerar a comunicação e diminuir a lentidão. No entanto, ainda não entendi a razão. Ocorre durante o redesenho, mas o estranho é que o redesenho em si não está freando. Mas o redesenho quando a comunicação é feita através de um recurso o faz. A razão para isto ainda não está clara.
Colocar em algum tipo de monitoramento de custo de tempo. Assim, você pode ver onde está diminuindo a velocidade. E como contornar isso.
Talvez o tenha tornado um pouco complicado. Não sei como está organizado dentro de seu motor. Eu só estava usando lógica.
Colocar em algum tipo de monitoramento de custo de tempo. Para ver onde está desacelerando. E como contornar isso.
Talvez o tenha tornado um pouco complicado. Não sei como está organizado dentro de seu motor. Eu só estava usando lógica.
A lógica o aproximou do ponto, e em geral, você entende corretamente.
Hoje vou tentar chegar ao fundo das causas de frenagem. O seguinte é claro - o redesenho em si não está diminuindo a velocidade. A escrita e a leitura do recurso também não é lenta. Mas juntos ficamos lentos.
Há monitoramento, qual operação leva quanto tempo? Elas devem ser realizadas seqüencialmente. O Expert Advisor as executa, capturando dados e enviando-os para o motor a uma freqüência de, digamos, 30 ms. Quando um fio é enviado para o motor, ele está pronto para receber? Ou o que ele faz?
Verificando tudo agora.
O motor a 30ms lê o recurso de mensagem do EA, e o EA, na mesma freqüência, lê o recurso de mensagem do motor. Na mesma freqüência, ambos escrevem suas mensagens um para o outro (se houver alguma coisa para escrever). Tudo isso não causa nenhuma desaceleração. Além disso, o redesenho, por si só, não causa frenagem.
Entretanto, a desaceleração aparece se houver uma combinação de redesenhar e escrever/leitura do recurso no lado do Motor. Porque isso ainda não está claro. Descobrindo isso.
Verificando tudo agora.
O motor a 30ms lê o recurso de mensagem do EA, e o EA, na mesma freqüência, lê o recurso de mensagem do motor. Na mesma freqüência, ambos escrevem suas mensagens um para o outro (se houver alguma coisa para escrever). Tudo isso não causa nenhuma desaceleração. Além disso, o redesenho, por si só, não causa frenagem.
Entretanto, a desaceleração aparece se houver uma combinação de redesenhar e escrever/leitura do recurso no lado do Motor. Porque isso ainda não está claro. Verificando-o.
Talvez um descasamento: EA e motor, 1 - ambos enviam um ao outro, 2 - ambos recebem, seus ciclos OnTimer não estão sincronizados. Esperando o momento da sincronização aleatória para trabalhar normalmente. Poderia ser esta a razão?