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
Mais de uma vez eu já vi situações em que o Terminal carrega a CPU 100% a ponto de não reagir a nada.
Depois olhei para os troncos e vi que havia saltos selvagens de carrapatos no OnTick. Entretanto, se eu escrever corretamente um EA, esta situação desastrosa não afetará os resultados comerciais. Analisei especificamente, tudo está claro.
Pergunto-me quão difundidos são os mecanismos para lidar com os atrasos nos Produtos de Mercado. Eu nunca vi nenhuma menção à potência da máquina para funcionar. O ping mínimo é um sim.
Onde você estava lançando-as?
Se em VPS por 2-5 dólares, então atrasos em dezenas e centenas de milissegundos são facilmente pegos em qualquer função WinAPI dificilmente séria. Tudo abranda a partir do nível do hipervisor, transformando uma máquina virtual em uma apresentação de slides.
Explicado acima.
Não é a GetMicrosecondsCount que está desacelerando, é o sistema operacional que está quantificando os recursos da CPU para qualquer thread em seu VPS estrangulado. Para qualquer função, qualquer ação, qualquer programa dentro de sua UPU.
Bem, nenhuma casca de CPU pode cortar e alocar recursos de forma justa quando tem 20 (isso ainda é respeitável) sistemas operacionais com 1500 fios de execução por cópia. Pegue 8-16 núcleos e distribua-os em 20 * 1.500 = 30.000 (trinta mil pistas físicas).
No meu caso (caixa virtual com vin7 + 2 núcleos + 16 GB de RAM inteiramente em meu próprio hardware, sem mais nada rodando), de onde vêm os 2-3 µs periódicos?
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
MT5 e Velocidade em Combate
Andrey Khatimlianskii, 2020.10.05 10:19
Não realmente uma UPU, mas uma máquina virtual sobre hardware alugado:
No meu caso (caixa virtual com win7 + 2 núcleos + 16GB de RAM em seu próprio hardware sem mais nada girando), de onde vêm os 2-3 µs periódicos?
Esse é o preço da virtualização dupla.
Especialmente porque o VirtualBox não é um hipervisor completo do tipo Hyper-V, mas vive em cima de seu sistema operacional de desktop atual (Windows 7 também?) que tem um shell de CPU feito sob medida para um caso de uso diferente.
Portanto, você tem: Windows 7/10 -> VirtualBox -> Windows 7. Essencialmente, dois níveis de virtualização, sendo o primeiro desconhecido as aspirações do VirtualBox, vendo-o apenas como um programa regular. A alocação de recursos da CPU (o rosqueador) está claramente aparafusada.
Deveria ser: Hyper-V 2016/2019 -> Windows 2016/2019
Não é a GetMicrosecondsCount que está diminuindo a velocidade, é o sistema operacional que está quantificando os recursos da CPU para qualquer thread em seu VPS estrangulado. Para qualquer função, qualquer ação, qualquer programa dentro de sua UPU.
Acho que uma discussão como esta vai fazer você pensar. Conselheiro.
Longe de atrasar tudo. É por isso que pude mudar para winmm::timeBeginPeriod(1)+winmm::timeGetTime() bastante inofensivo, obtendo velocidade como GetTickCount, mas sem o temido limite de 16 ms. Entretanto, os produtores do mercado não estão autorizados a fazer isso, pois é uma DLL. É pouco provável que você faça uma versão regular de milissegundos.
A função da MQL5 para minimizar todas as janelas e a própria aplicação é uma grande idéia. Vamos trabalhar nisso.
Aqui está outra coisa.
terminal em um VPS, então ela se oporá fortemente a que tudo seja repelido abruptamente. Ele mesmo pode e deve minimizar as janelas se sair da sessão do RDP.
Aqui está um exemplo do que eu queria dizer.
Ambos os servidores são corretores diferentes, estão na mesma área, podem estar na mesma localização.
O cartão de serviço sugere que a AMP seja localizada no Reino Unido.
E, por alguma razão, oferece em NL.
Por quê? Se houver um vpc mais próximo.
Acho que você descobrirá que esse é um argumento que o fará pensar. Conselheiro.
Longe de atrasar as coisas. É por isso que pude mudar para winmm::timeBeginPeriod(1)+winmm::timeGetTime() bastante inofensivo, obtendo velocidade como GetTickCount, mas sem o temido limite de 16ms. Entretanto, os produtores do mercado não estão autorizados a fazer isso, pois é uma DLL. É pouco provável que você esteja fazendo uma versão regular de milissegundos.
Bem, você é um mestre em testes de estresse de corrida sem correlação ou controle de razoabilidade.
É claro que a medição de microssegundos requer recursos para poder medir intervalos 1000 vezes menores do que um milissegundo.
Se ocasionalmente for necessário medir os intervalos com maior precisão, então use microssegundos. E isso lhe custará 0 microssegundo.
Se você está preparado para chamar milhões de vezes a auto-medição, você provavelmente está se engajando em auto-ilusão.
Em um VPS asfixiado, o overclocking do temporizador do sistema via timeBeginPeriod é arriscado. Você só vai aumentar a sobrecarga de sua CPU:
Caso contrário, o sistema operacional há muito teria tornado o GetTickCount/GetTickCount64 preciso e alegre com a precisão gratuita. Mas não, você terá que pagar pela precisão deste temporizador.
Aqui está um exemplo do que eu queria dizer.
Ambos os servidores são corretores diferentes, estão na mesma área, podem estar na mesma localização.
O cartão de serviço sugere que a AMP seja localizada no Reino Unido.
E, por alguma razão, oferece em NL.
Por quê? Se houver uma PSTN mais próxima.
Conhecemos os geo-pontos dos servidores, e aqui as posições dos servidores de corretagem são construídas a partir de bases GeoIP.
E muitas vezes acontece que as informações não correspondem à realidade. Portanto, nunca devemos assumir que a posição do corretor seja precisa.
Analisaremos isso com mais detalhes amanhã, pois precisamos verificar e digitalizar tudo de novo manualmente para responder à pergunta.
Esse é o preço da virtualização dupla.
Especialmente porque o VirtualBox não é um hipervisor completo do tipo Hyper-V, mas vive em cima do seu sistema operacional atual ( Windows 7 também?) que tem um shell de CPU feito sob medida para um caso de uso diferente.
Portanto, você tem: Windows 7/10 -> VirtualBox -> Windows 7. Essencialmente, dois níveis de virtualização, sendo o primeiro desconhecido as aspirações do VirtualBox, vendo-o apenas como um programa regular. A alocação de recursos da CPU (o Threadheduler) é claramente fodida.
Deveria ser: Hyper-V 2016/2019 -> Windows 2016/2019
Não, eu tenho virtualizadores girando em meu CentOS. Mas eu não sou competente para continuar este diálogo.