MT5 e velocidade em ação - página 69
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
como você prevê isto - processamento paralelo em uma única linha?
Um ciclo de eventos.
E em geral, é um problema do desenvolvedor porque tudo é executado em um único fio.
Acontece que a Visão Geral do Mercado é processada de forma assíncrona, e os manipuladores nos programas dos usuários, de forma síncrona.
É apenas chicardous, não há palavras.
Obrigado pelo feedback sobre as estatísticas! Os desfasamentos OnTick/OnBook parecem estar lá para todos. Dormir(1) é de 1 ms ou 15 ms. Não está claro porque depende.
Todo mundo parece ter um atraso OnTick/OnBook.
Penso que você sabe que OnTimer() não pode ser chamado com mais freqüência do que 10-16 milissegundos. É lógico assumir que outras funções OnXXX também não são chamadas com mais freqüência. Talvez seja por isso que seus atrasos estão ocorrendo?
Penso que você sabe que OnTimer() não pode ser chamado com mais freqüência do que 10-16 milissegundos. É lógico assumir que outras funções OnXXX também não são chamadas com mais freqüência. Talvez essa seja a razão de seus atrasos?
Não logicamente, os manipuladores não estão vinculados à freqüência/resolução do temporizador GetTickCount. Os eventos são acionados instantaneamente no momento em que acontecem.
OnTimer também não está vinculado a erro de 16ms. É fácil obter um timer de 1ms na grande maioria dos casos, se o computador não estiver morto e não estiver 100% carregado.
O problema com quase todos os testes do fxsaber é que ele tenta medir os outliers de chamadas únicas em vez de fazer a média do conjunto e não quer entender a realidade do despachante de fios.
Ele tem:
Métodos de luta para se aproximar do tempo de reposição:
Consequentemente, em um VPS regular, os terminais (assim como quaisquer outros programas) sempre sofrerão atrasos inesperados. Quanto mais barato/sobre-vendido for o VPS, mais problemas.
Pergunte-se em seu VPS, o SR-IOV está habilitado e há algum driver de rede especial mais recente (apenas instalado manualmente) para ele? Em 99% dos casos, não, pois quebra a migração de virtualizações através do zoológico de hardware. E sem isso, atrasos adicionais são garantidos simplesmente por causa do dobro (no host e virtual) da transmissão/processamento de pacotes de rede e do aumento do número de interrupções.
Nosso serviço VPS é muito menos propenso a isso, tanto em termos de arquitetura quanto em termos de terminais leves sem GUI.
Não é lógico, os manipuladores não estão vinculados à freqüência/resolução do temporizador GetTickCount. Os eventos são acionados instantaneamente no momento da ocorrência.
OnTimer também não está vinculado a erro de 16ms. É fácil obter um timer de 1ms na grande maioria dos casos, a menos que o computador esteja morto e 100% carregado.
O problema com quase todos os testes do fxsaber é que ele tenta medir os outliers de chamadas únicas em vez de fazer a média do conjunto e não quer entender a realidade do despachante de fios.
Ele tem:
Métodos de luta para se aproximar do tempo de reposição:
Consequentemente, em um VPS regular, os terminais (assim como quaisquer outros programas) sempre sofrerão atrasos inesperados. Quanto mais barato/sobre-vendido for o VPS, mais problemas.
Pergunte-se em seu VPS, o SR-IOV está habilitado e há algum driver de rede especial mais recente (apenas instalado manualmente) para ele? Em 99% dos casos, não, pois quebra a migração de virtualizações através do zoológico de hardware. E sem isso, atrasos adicionais são garantidos simplesmente por causa do dobro (no host e virtual) da transmissão/processamento de pacotes de rede e do aumento do número de interrupções.
Nosso serviço VPS está sujeito a ele por ordens de magnitude menor, tanto em termos de arquitetura como em termos de terminais leves sem GUI.
E agora imagine quantas vezes o desempenho dos programas dos usuários seria mais lento em uma máquina tão otimizada, se os manipuladores nos programas fossem executados de forma assíncrona.
Não entendo a sensação de super atualização e super otimização do hardware da máquina, se os manipuladores no programa do usuário são a priori executados de forma síncrona.
Para o próprio terminal e seu funcionamento interno, talvez, a otimização descrita acima seja útil. Para programas de luta de usuários, duvido.
Porque a execução consecutiva de manipuladores em programas de usuários reduz todo o potencial de qualquer máquina super-optimizada.
O problema não está no hardware, mas na arquitetura do trabalho interno do terminal.
E agora imagine quantas vezes mais rápido será a execução dos programas do usuário em uma máquina tão otimizada, se os manipuladores nos programas forem executados de forma assíncrona.
Não entendo a sensação de super atualização e super otimização do hardware da máquina, se os manipuladores no programa do usuário são a priori executados de forma síncrona.
Para o próprio terminal e seu funcionamento interno, talvez, a otimização descrita acima seja útil. Para programas de luta de usuários, duvido.
Porque a execução consecutiva de manipuladores em programas de usuários reduz todo o potencial de qualquer máquina super-optimizada.
O problema não está no hardware, mas na arquitetura de operação interna do terminal.
Não haverá aceleração. Por favor, apresente seus cálculos, pelo menos em números aproximados, provando uma aceleração múltipla.
Uma corrida por recursos? Criação descontrolada de novos fios? Conflitos por nada?
Você quer abrandamentos inexplicáveis?
No modelo baseado em eventos, todos os eventos foram sempre em formação, um de cada vez. Mastigado - mastigado.
Nosso serviço VPS é muito menos propenso a isso, tanto em termos de arquitetura quanto em termos de terminais leves sem GUI.
Se houver atrasos em seu serviço VPS, você irá levá-lo a sério?
Quem usa VPS da MQ, favor compartilhar os resultados dos seguintes programas.
Se houver atrasos em seu serviço VPS - você irá levá-lo a sério?
Quantas vezes será preciso dizer que com tantos (milhares) fios por número limitado de núcleos é uma loucura falar de estabilidade de alocação quântica de tempo por fio?
É sempre garantido que você terá falhas em amostras aleatórias de qualquer instrução, incluindo as mais simples de montagem como inc eax. Isto é arquitetônico e devido às limitações físicas de "alocar honestamente quanta de tempo de milhares de fios para um pequeno número de núcleos".
Deixe de ser burro e continue capturando rajadas simples por milhão de pedidos.
Deixe de ser estúpido e continue capturando os únicos outliers por milhão de consultas.
Vejo o que está acontecendo com os espigões simples, obrigado pela explicação detalhada. No momento, não estamos discutindo SymbolInfoTick, mas sim desfasamentos de outro tipo, que ocorrem em quase todos os carrapatos.