MT5 e velocidade em ação - página 92

 
fxsaber:

Monitorar a discrepância entre TimeLocal e TimeCurrent.

E se o TimeLocal() vai se atrasar nestas situações, será a causa no sistema operacional?
 
Vasiliy Pushkaryov:
E se o TimeLocal() ficar para trás em tais situações, será a causa no sistema operacional?

O TimeLocal não está muito atrás. A discrepância é um corretor.

 
Vasiliy Pushkaryov:

Talvez alguém experiente, qual poderia ser a razão de tais pendências ou lentidão?

A primeira coisa que vem à mente é um bug no código que faz com que o cálculo seja executado por um tempo muito longo (por exemplo, no ciclo de 1 a 10 a int inteira é executada por causa do bug)

 
fxsaber:

O TimeLocal não está muito atrás. A discrepância é um corretor.

Obrigado. Vou tentar.
 
Andrei Trukhanovich:

A primeira coisa que vem à mente é um bug no código que aciona um cálculo que leva muito tempo (por exemplo, no ciclo de 1 a 10 a int inteira é executada por causa do bug).

Está escrito na ajuda que uma EA em loop não pode interromper o funcionamento de outros programas. Tudo congela e então começa a funcionar novamente.

Eu tenho 7 terminais MT4 e três MT5 funcionando em paralelo. Talvez não haja capacidade suficiente?



 
Vasiliy Pushkaryov:

Parece estar escrito na ajuda que uma EA em loop não pode interromper outros programas. E aqui tudo congela, depois tudo começa a funcionar novamente.

Sim, estranho, eu só vi a guia dos especialistas, não vi os troncos na primeira vez.

Existem 7 terminais MT4 e três MT5 funcionando em paralelo. Talvez não haja capacidade suficiente?

Se assim for, então o mais provável é que todos os terminais sejam desacelerados. Além disso, a carga da CPU deve apenas ser dimensionada para 100% neste caso

 

O conjunto TerminalA - terminais que possuem dados de ping(xxx ms) para pontos de acesso.

O conjunto TerminalB - terminais que não possuem dados de ping(n/a) para pontos de acesso.


Os terminais de ambos os conjuntos podem ser conectados ao mesmo Ponto de Acesso e comercializados da mesma forma - o OrderSend é enviado e as respostas são recebidas.


O TerminalA carrega o processador o mínimo possível.


TerminalB:

  • carrega a CPU o máximo possível.
  • após o reinício permanece TerminalB.
  • Após o "Rescan network" (manualmente via GUI) muda o tipo para TerminalA. Assim, ele pára de carregar a CPU.


Se você encontrar uma carga de CPU inexplicavelmente alta, tente fazer uma nova digitalização. Isto me ajudou a mudar todo o TerminalB para TerminalA.

 

Não sei por que, mas meu corretor parece ter mais volume de negócios, número de negociações e número de contas de negociação ativa na MT5 do que na MT4.

Infelizmente, só há informações agregadas por plataforma.

Количество закрытых позиций :129 714
Торговый оборот ($) :$ 5 747 296 372
Активных счетов :498

Mas as evidências circunstanciais sugerem que o MT5 está à frente do MT4. As razões para este estado de coisas são apenas para ser adivinhadas.


O que eu sei sobre os clientes:

  • >95% dos negócios (~99% do faturamento) são de auto-negociação.
  • Alguns clientes têm terminais MT5 comendo > 10 gigas de memória (caches históricos), MT4 com o mesmo volume < 1 gigas. Apesar disso, estão prontos para pagar em excesso por VPS mais poderosos, mas negociam exatamente em MT5, e não em 4.
  • Quase todos eles são escalpadores. Os principais lucros são contabilizados no comércio de apartamentos noturnos e noturnos.
  • A alta atividade (para o lado positivo em comparação com outros corretores) durante o período de prorrogação - enormes spreads.
 
fxsaber TimeCurrent.

Obrigado pela dica. Apanhei esta situação. Em OnTimer() monitorou a discrepância entre TimeLocal() e TimeCurrent()


Desde ontem à noite às 21:58 TimeCurrent() começou a retornar na mesma hora. Lançado hoje às 00:08. Ou seja, pouco mais de duas horas tiveram esta situação de todos os personagens.

 

Não é uma máquina remota (não VPS) com boas especificações e um ping para o servidor comercial <4ms viu muitos casos de atrasos regulares ao visualizar os logs do Terminal (b2958).


Levei a primeira que vi para demonstração aqui.

2022.01.18 23:00:09.375  Trades  '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.752  Trades  '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.769  Trades  '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms


A modificação do limitador durou oito segundos. A maioria das modificações leva mais ou menos esse tempo.

2022.01.18 23:11:00.751 Trades  '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.761 Trades  '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.763 Trades  '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms


Mesmo por um ping de 4ms é muito, mas ainda assim nada comparado a oito segundos.


Somente terminais MT5 estão funcionando nesta máquina e a carga média da CPU é de ~1%. A análise tem mostrado que durante a frenagem os picos de carga chegam a 100% quando o mercado e as ordens comerciais estão muito ativos. Como resultado, leva MUITO tempo para receber resposta do servidor comercial ao terminal. Em caso de lentidão, pedi informações ao corretor. No lado do servidor comercial tudo é instantâneo e o pedido chega ao servidor a partir do terminal na primeira linha. Isto é, o envio de pedidos não retarda, os atrasos acontecem ao receber a resposta ao terminal.


Duvido que os desenvolvedores sejam capazes de melhorar qualquer coisa aqui. Quem é MUITO ativo no comércio, por favor, compartilhe suas observações sobre este tópico com seus registros.