Aceitação de ordens SL/TP - página 2

Novo comentário
 
Esta informação deve ser enviada a todos os mega-HFTs da MT, brincando)) O custo da barateza é este.
 
fxsaber:

Tem sido afirmado repetidamente em outro tópico que até mesmo o Terminal abranda devido a um grande número de fatores. Como conseqüência, um Servidor Comercial muito mais complexo está fadado a desacelerar ainda mais. Eu ainda espero que a otimização algorítmica ainda seja possível. Mesmo um atraso de 5 ms já é muito ruim. O que dizer de centenas de milissegundos.

E quanto às contas demo não é muito interessante (posso depurar qualquer plug-in lá, testar novo hardware, etc.).

E encontrei no máximo 17 ms em contas ao vivo (não estou dizendo que não é longo, simplesmente não pode ser comparado com 30 segundos).

Daí a suspeita de uma configuração de servidor em cascata.

 
Andrey Khatimlianskii:

Que na demonstração não é muito interessante (você pode depurar qualquer plugin lá, testar novo hardware, ...).

E em contas ao vivo encontrei no máximo 17 ms (não estou dizendo que não é suficiente, apenas não se compara com 30 segundos).

Infelizmente, eles não mostraram quantos pedidos eles verificaram.

Fórum sobre comércio, sistemas comerciais automatizados e estratégias comerciais de teste

Aceitação de ordens SL/TP

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

Daí a suspeita de uma configuração de servidor em cascata.

O corretor confirmou o problema e conseguiu encontrá-lo e consertá-lo (estará disponível após o fim de semana). Mas é difícil dizer se isso foi devido ao MT5.


Mas atirar pedras na direção do MT5 pode definitivamente ser feito por esta situação.

Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos

Aceitação de ordens SL/TP

fxsaber, 2020.11.25 00:47

Não sei, eu estava tentando conseguir que meu corretor liberasse meu pedido, mas eu estava me apaixonando pela situação em que eu estava quando negociei no Terminal que está na mesma máquina onde o Trade Server está instalado. Isto é, com um ping muito baixo e uma única conta de negociação para o Trading Server.



O Terminal e o Servidor estão na mesma máquina. Carga zero. Um novo take recebeu tal alerta.

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Log do servidor.

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Aceite-tick no servidor.


Confirmação completa dos dados do roteiro de que há um problema. Dentro do servidor com carga zero, houve um atraso de 4ms.

 
Andrei Trukhanovich:

outra explosão cerebral do fxsaber.

Sente-se especialmente mal quando você percebe quanto tempo desperdiçou. E que ninguém fará isso por você.
 

Parece ser realmente um problema no servidor. Esta é uma conta demo MT5

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

Em uma conta real com o mesmo corretor, o roteiro retorna resultados zero. Há mais de 3000 transações na conta.

 
Enrique Dangeroux:

Em uma conta real no mesmo corretor, o roteiro retorna resultados zero. Há mais de 3.000 transações na conta.

Isto é suspeito. Eu não encontrei nenhum atraso em minhas contas.

 

Não tenho certeza se está relacionado. Mas eu recebo muitos deles. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Erros que acionam Tomar quando a posição é alterada. Então o Take é acionado, desvia algumas vezes, depois pendura, eu mudo o tp para zero para fazer marcha atrás e cai.


Antes de mudá-lo, eu o verifico

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

Para que a posição não congele.

 
fxsaber :

Isto é suspeito. Em nenhuma parte de minhas contas encontrei a falta de desfasamentos.

Eu pensava o mesmo, mas uma investigação mais profunda mostrou que havia cerca de 100 por Tomar só os fechamentos

Portanto, para um tamanho de amostra pequeno.

 

Fórum sobre comércio, sistemas comerciais automatizados e estratégias comerciais de teste

Aceitação de ordens SL/TP

Enrique Dangeroux, 2020.11.25 17:20

Não tenho certeza se isto está relacionado. Mas eu recebo muitos deles. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Também tenho todo o meu registro em tais mensagens. Talvez após o fim de semana a situação mude.

Fórum sobre comércio, sistemas comerciais automatizados e estratégias comerciais de teste

Aceitação de ordens SL/TP

fxsaber, 2020.11.25 16:30

O corretor confirmou o problema e conseguiu encontrá-lo e consertá-lo (estará disponível após o fim de semana). Mas é difícil dizer se isso foi devido ao MT5.

 

Consideremos esquematicamente alguns algoritmos da plataforma de negociação. Para simplificar, vamos supor que existe apenas uma LP(provedor de liquidez).


Ordem limite.

  1. O preço da LP satisfaz o preço da ordem de limite do pregão.
  2. O Gateway envia esta ordem limite para a LP com um curto prazo de validade.
  3. Se o Gateway receber um redirecionamento para uma parte do volume limite, o Gateway repetirá tudo a partir do ponto 1 para o volume restante, caso o tick da LP tenha mudado durante o tempo de processamento do limite.

Um bom Gateway (com o algoritmo acima) é independente da plataforma comercial específica ao executar o Limitador.

O algoritmo é quase looped e independente de plataforma. A proteção LP contra spam está contida no ponto 3.


Nível TP de uma posição aberta.

  1. Um carrapato veio da LP
  2. O preço é enviado para a MT5 como um novo tick.
  3. Se a posição não for bloqueada e o preço do novo tick atender ao nível TP, o MT5 cria um pedido TP.
  4. O Gateway vê que nasce uma ordem TP, bloqueia a posição e faz a p.2 do algoritmo de ordem limite.
  5. Se receber um rejack, então o MT5 envia a ordem TP para a história com um status de rejeição. A posição é desbloqueada.

O algoritmo não é em loop e é dependente da plataforma. Há proteção contra spam LP.


Este algoritmo tem duas desvantagens além dos custos de comunicação Gateway-MT5.

  • Foi demonstrado nesta linha que o nascimento de uma ordem TP (ver ponto 3) em MT5 tem um atraso. Portanto, a probabilidade de uma ordem TP ser capaz de executar é menor do que se não houvesse atraso.
  • Um pedido TP em MT5 não pode ser criado sem um novo tick. Isto significa que se um redirecionamento for recebido, o Gateway não fará nada até que um novo tick tenha chegado no MT5, satisfazendo o nível TP. E o tempo precioso para tentar executar o nível TP é perdido por causa disso. Isto também piora o FillRate.


Melhorias.

Smart Gateway no algoritmo de nível TP de uma posição aberta tem p.6:

6. Se um novo tick foi recebido da LP durante o redirecionamento, seu valor real é reenviado para o MT5 como um novo tick - passe para o passo 2.

Este ponto adicional do algoritmo ainda contém proteção contra spam LP, mas engana o MT5 para realizar o ponto 3. E nenhum tempo precioso é perdido esperando pelo novo tick.


Realidade.

Destes dois algoritmos (mesmo no caso do ponto 6 do segundo algoritmo), segue-se o seguinte.

Uma ordem de limite MT5 tem uma taxa de preenchimento superior ao seu equivalente na forma de uma posição aberta de nível TP. Esta é a razão pela qual podemos frequentemente encontrar situações durante uma rolagem no MT5-Hedge onde a ordem limite é executada, mas sua contraparte TP não é. Em tal caso, CloseBy é feito e a ordem de limite é reexecutada com o volume correspondente.


Conclusão.

Para aumentar o FillRate em MT5, transferir os níveis TP de posições em aberto para ordens de limite MT5.

12345678
Novo comentário