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

Novo comentário
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 ainda é um problema atual

A última vez que verifiquei, este problema foi resolvido no corretor mencionado.

 

Caros desenvolvedores, por favor, respondam a seguinte pergunta sobre arquitetura. As informações são necessárias para uma aplicação em combate. Sem reivindicações.


Há dois limitadores com o mesmo preço e lotes diferentes. De que depende o pedido deles na seqüência de acionamento?

Tenho várias respostas a esta pergunta.

  1. Sobre o lote.
  2. No número do bilhete.
  3. A partir da última modificação do preço de abertura.
  4. Desde a última modificação de uma ordem (por exemplo, o nível de take foi atualizado em uma ordem Limit).

Se entendi corretamente, então, após modificar o preço de abertura, o Limitador é devidamente incorporado na lista de todos os Limitadores do servidor, ordenado pelo preço de abertura. Então a resposta à pergunta se resume a: ela está embutida no início da lista de pedidos com o mesmo preço ou no final?


A mesma pergunta não é sobre limites, mas sobre fichas. De que depende a ordem de acionamento de tomadas idênticas? É uma posição de identificação ou algo mais?


Deixe-me explicar como isto pode ajudar no combate. Por exemplo, eu tenho dois limitadores (ou tees de posição) no mesmo nível, mas com lotes diferentes. Se a execução do limite (tee) depender da última modificação, então posso aumentar o FillRate simplesmente modificando os limitadores em incrementos de lote ascendente.


Provavelmente, somente alguém que escreveu a implementação da parte correspondente do servidor MT5 sabe a resposta a esta pergunta.

 
Andrei Trukhanovich:

trabalhar em conjunto com um corretor para encontrar o gargalo

O que é isso, abelhas versus mel?)
 
fxsaber:

Há dois limitadores com o mesmo preço e lotes diferentes. De que depende sua ordem na seqüência de acionamento?

Tenho várias respostas a esta pergunta.

  1. Sobre o lote.
  2. No número do bilhete.
  3. A partir da última modificação do preço de abertura.
  4. Desde a última modificação de um pedido (por exemplo, o nível de take foi atualizado no limite).

Acho que a variante 4 foi usada na quarta. Ou seja, qualquer modificação moveu o pedido para o final da fila do nível de preço correspondente.

 
secret:
É como, abelhas versus mel?)

neste momento em particular nesta situação particular, é mutuamente benéfico e foi feito. uma rara coincidência.

 

Os pedidos TP em MT5 são notáveis, pois podemos investigar o FillRate (que parte do pedido é preenchida).

A análise de dezenas de milhares de tais pedidos mostrou que o FillRate depende muito do símbolo. Se um pacote de pedidos TP é acionado simultaneamente, então o FillRate diminui conforme o número do pedido na embalagem aumenta.

Outras nuances específicas também foram reveladas. Mas isto já está sendo discutido com o corretor.


A receita para aumentar o FillRate: combinar todos os mesmos carrapatos e limitadores em um limite MT5 comum.


Entretanto, estes dados são apenas um bônus para este tópico. O problema independente do corretor é que o MT5 está atrasado com carrapatos e conseqüentemente com a aceitação de ordens pendentes (incluindo níveis SL/TP).


E após um redirecionamento, o MT5 espera toda vez que o próximo tick verifique se o preço satisfaz o nível TP (ou limite) ou não. Isto pode levar até segundos. E a verificação deve ser sempre feita imediatamente após o regimento (ou preenchimento parcial).

Arquivos anexados:
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick é acionado alguns milissegundos depois que o tick é escrito para o servidor comercial.

// Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10;  // EMA-period
input int inAmount = 100; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

  MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


  return((StructToTime(time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0;
int MaxValue = 0;
int MinValue = INT_MAX;
int Amount = 0;

void OnTick()
{
  static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

  MqlTick Tick;
  
  const long time = TimeLocalMsc(); // Локальное время в миллисекундах

  if (SymbolInfoTick(_Symbol, Tick))
  {
    const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax(Value, MaxValue); // Максимальное значение.
    MinValue = MathMin(Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
    if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
    #define  TOSTRING(A) #A + " = " + (string)(A) + "\n"      
      Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST)));
      
      ExpertRemove();
    }
  }
}


Resultado.

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger(TERMINAL_PING_LAST) = 42


Foram processados 100 carrapatos. A defasagem de chegada entre o servidor e o terminal do tick varia de um a oito milissegundos. A média é um pouco mais de quatro milissegundos. Isto é igual à defasagem do acionamento da ordem TP, que é onde este ramo começou.


O próprio atraso está dentro do servidor MT5. O canal Server->Terminal não tem nada a ver com isso.


Um grande pedido aos desenvolvedores para eliminar este atraso. Agora com zero pings temos um atraso constante de ticks que chegam não só ao terminal, mas também ao Servidor. Em particular, a ordem aceita.


ZS Para aqueles que despem os corretores de cozinha através de arbitragem, este atraso embutido é como mana do céu. Isto é, os corretores incorrem em riscos adicionais substanciais.

 
Em que servidor você verificou?

Em que ferramenta e em que gateway/dataaphide você usou para formar os dados iniciais?

Se o tempo foi gerado por um provedor de cotação em seu lado remoto (por exemplo, gateway de troca) e não pelo servidor MT5 em si, então pode haver uma lacuna.

Que processos de fundo você poderia esquecer, como testes de estresse com dezenas e centenas de milhares de negócios paralelos?
 

Renat Fatkhullin:
На каком сервере проверяли?

Verificado em muitos servidores. Incluindo MQ-Demo.

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

Aceitação de ordens SL/TP

fxsaber, 2020.11.25 00:47

Resultado da sua execução no MQ-Demo.

Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439
Calculation time = 00:00:11.328, Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205
Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0

Orders (2) before 726444166 with PositionID = 725926764:
------------------------
Checked Orders = 0
------------------------


O roteiro afirma ter encontrado uma ordem TP e um tique que foi o gatilho para sua criação (destacado em cores no texto). Parece que se o preço atingiu o nível TP de uma posição aberta no servidor comercial (especialmente na demonstração), a ordem TP correspondente deve ser criada (não necessariamente executada) imediatamente. Entretanto, nesta situação não aconteceu imediatamente, mas depois de 357 milissegundos!


Em qual instrumento e em qual gateway/datafeto formaram-se os dados iniciais?

Verifiquei as ferramentas forex, RannForex-Server, AMTS-gateway. Outras configurações precisam ser esclarecidas.

Se o tempo foi formado pelo fornecedor de cotações em seu lado remoto (por exemplo, o gateway de troca), e não pelo servidor MT5 em si, então a lacuna pode ser.

Acredito que o servidor MT5 estava se formando em uma máquina com zero ping. Mas requer esclarecimento para uma garantia de 100%. No entanto, o acima exposto mostrou que mesmo em seu servidor o problema.

 
fxsaber:

Ao investigar a execução de ordens TP, notei que algumas ordens TP foram criadas com um atraso significativo em relação aos carrapatos que as aceitavam.

O debriefing mostrou que esta situação se repete não apenas em corretores diferentes, mas também na situação em que a negociação é feita no Terminal, que está na mesma máquina que o Servidor de Negociação. Isto é, com um ping muito baixo e uma única conta de negociação para o Trading Server.

Eu os encorajo a compartilhar os resultados de suas contas. Ajude a melhorar o MT5!

Você "esqueceu" um detalhe muito pequeno - você verificou 58.000 pedidos e encontrou apenas um caso de excesso a 300 ms. E você deveria ter se concentrado claramente nisto (1 em 58.000) durante estas verificações.

Assim como nos anteriores com cheques de milhões de dólares, onde você também procurou por um único outlier e fingiu que era um comportamento normal.


Verificamos os logs do servidor e pudemos ver que nossa virtualização com o servidor MetaQuotes-Demo estava fisicamente doente naqueles segundos (em 2020.09.30 19:07 por 4 segundos), porque havia cerca de 15 milhões de contas e cerca de 2 milhões de posições abertas, e enquanto isso algo estava acontecendo nos servidores virtuais vizinhos e no hipervisor.

Em qualquer caso, vamos investigar mais a fundo, embora haja sempre picos únicos em qualquer sistema.

12345678
Novo comentário
Razão: