Erros, bugs, perguntas - página 2220

Novo comentário
 
1861 - impossível abrir uma demonstração em Alpari. A escolha de um corretor não funciona.
 
fxsaber:

Na minha opinião, isto é um bug quando uma encomenda está no servidor de comércio, mas após o OrderSend síncrono no terminal não há sinal dele.

Decidi verificar quanto tempo duram essas ordens fantasma quando a ordem está presente no sistema mas não no terminal.

// Советник отслеживает длительность ситуаций, когда ордер отсутствует среди текущих и исторических

#define  TOSTRING(A)  #A + " = " + (string)(A) + "\n"
#define  TOSTRING2(A) #A + " = " + EnumToString(A) + " (" + (string)(A) + ")\n"

bool OrderIsExist( const ulong &OrderTicket )
{
  return(OrderTicket ? OrderSelect(OrderTicket) || HistoryOrderSelect(OrderTicket) : true);
}

void OnTradeTransaction ( const MqlTradeTransaction &Trans, const MqlTradeRequest&, const MqlTradeResult& )
{
  static bool PrevIsExist = true;
  static ulong StartTime = 0;
  static ulong MaxInterval = 0;
  
  const ulong NowTime = GetMicrosecondCount();
  const bool IsExist = OrderIsExist(Trans.order);
    
  if (!IsExist)
  {
    Print(TOSTRING2(Trans.type) + TOSTRING(Trans.order) +
          TOSTRING(OrderSelect(Trans.order)) + TOSTRING(HistoryOrderSelect(Trans.order)));       
  
    if (PrevIsExist) 
      StartTime = NowTime;
  }
  else if (!PrevIsExist)
  {
    const ulong Interval = NowTime - StartTime;
    
    Print(TOSTRING(Interval) + TOSTRING2(Trans.type) + TOSTRING(Trans.order) +
          TOSTRING(OrderSelect(Trans.order)) + TOSTRING(HistoryOrderSelect(Trans.order)));       
    
    if (Interval > MaxInterval)
    {
      MaxInterval = Interval;
      
      Comment(TOSTRING(MaxInterval) + TOSTRING(Trans.order)); // mcs.
    }
  }
          
  PrevIsExist = IsExist;
}


O resultado é

2018.06.21 00:10:31.047 Trans.type = TRADE_TRANSACTION_ORDER_DELETE (2)
2018.06.21 00:10:31.047 Trans.order = 2210967406
2018.06.21 00:10:31.047 OrderSelect(Trans.order) = false
2018.06.21 00:10:31.047 HistoryOrderSelect(Trans.order) = false
2018.06.21 00:10:31.047 
2018.06.21 00:10:31.080 Interval = 32643
2018.06.21 00:10:31.080 Trans.type = TRADE_TRANSACTION_HISTORY_ADD (3)
2018.06.21 00:10:31.080 Trans.order = 2210967406
2018.06.21 00:10:31.080 OrderSelect(Trans.order) = false
2018.06.21 00:10:31.080 HistoryOrderSelect(Trans.order) = true


Uma ordem está presente no sistema mas não no Terminal durante 32 milissegundos! Imaginem as consequências se a lógica comercial fosse executada neste intervalo ...


É interessante que as ordens fantasma estão mais frequentemente presentes apenas emTRADE_TRANSACTION_ORDER_DELETE e em TRADE_TRANSACTION_DEAL_ADD (muito mais raras) tipos de transacção.


Muito mau matiz de plataforma.


ZZY A velocidade das transacções comerciais em 5 é, infelizmente, questionável.

Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
  • 2016.09.13
  • MetaQuotes Software Corp.
  • www.mql5.com
Многие трейдеры зачастую не задумываются над тем, как быстро доходит их заявка до биржи, как долго она там исполняется и когда торговый терминал трейдера узнает о результате. В результате они не знают, что легко могут улучшить качество исполнения своих сделок за счет более быстрой реакции и скорости проведения транзакций. 12 сентября 2016 года...
 
fxsaber:

Decidi verificar quanto tempo duram tais situações de ordem fantasma, quando uma ordem está no sistema mas não no terminal.


O resultado é


Durante 32 milissegundos, há uma encomenda mas não está no Terminal! Basta imaginar as consequências se a lógica de negociação fosse executada durante este intervalo.

Sim, isso não é bom. Como podem ver, estes resultados de transacção são enviados em pacotes diferentes. Devem ser num só.

 
Alexey Navoykov:

Como pode ver, estes resultados de transacção são enviados em pacotes diferentes, enquanto que deveriam ser num só.

Acontece que a encomenda pode ser fantasma logo após a OrderSend e o Expert Advisor paralelo com a OnTradeTransaction nem sempre consegue apanhar este estado. Isto é, a própria OnTradeTransaction por vezes abranda.


De um modo geral, existem atrasos arquitectónicos no MT5 em diferentes locais que dificilmente são eliminados. Estes são desfasamentos de chegadas de carraças e agora de transacções comerciais. Tem de ser claro sobre o que a plataforma é capaz de fazer se estiver a contar com a velocidade de execução. Por exemplo, carraças que chegam com um atraso decente, depois transacções... e eventualmente outra pessoa no MT5 ou noutra plataforma podem ultrapassar, mesmo que você mesmo esteja sentado mesmo ao lado da troca.

 
As transacções comerciais são feitas em pacotes prioritários, ultrapassando o resto. Isto reduz seriamente a latência.
 
Renat Fatkhullin:
As transacções comerciais vão em pacotes prioritários, ultrapassando os outros. Isto reduz seriamente a latência.

Como é possível que o guião detecte uma situação de ordem fantasma após a OrderSend, mas a OnTradeTransaction numa EA paralela não o faz (nem sempre, mas acontece)?

 
Renat Fatkhullin:
As transacções comerciais vêm em pacotes prioritários, ultrapassando os outros. Isto reduz seriamente a latência.

O problema é que as transacçõesTRADE_TRANSACTION_ORDER_DELETE eTRADE_TRANSACTION_HISTORY_ADD vêm em pacotes diferentes e é por isso que não importa qual a prioridade que têm, a latência da rede será de qualquer forma.E estas transacções devem ser executadas de forma sincronizada, uma após outra, sem qualquer estado intermédio. Ou seja, é uma operação atómica em essência, porque colocar uma ordem eliminada na lista histórica não tem nada a ver com uma troca.

Ou seja, há aqui duas opções: ou estas duas transacções se juntam num pacote, ou a primeira transacção não é executada no terminal até que a segunda chegue.

 
Alexey Navoykov:

Isto é, existem duas opções: ou ambas as transacções se juntam num pacote, ou a primeira transacção não é executada no terminal até que a segunda chegue.

Há situações em que TRADE_TRANSACTION_DEAL_ADD vem ANTES da transacção TRADE_TRANSACTION_ORDER_DELETE. Neste caso, mesmo antes de TRADE_TRANSACTION_ORDER_DELETE, a encomenda ainda é fantasma.

 

Os agentes remotos deixaram de optimizar

2018.06.22 14:05:24.901 SVA_03  pass 19 tested with error "task rejected by tester agent" in 0:00:00.000
2018.06.22 14:05:27.387 SVA_03  pass 19 tested with error "task rejected by tester agent" in 0:00:00.000

Presumo que seja por causa do novo compilador, como podem ser actualizados para o fazer funcionar?

Além disso, apenas uma parte do optimista passa 13 de 28 por causa deste erro.
 

Olhando através do código do pacote Alglib. Está cheio destas construções, o que torna o código mais difícil de ler:

         for(i_=0;i_<=nvars-1;i_++)
            tmp[i_]=xy[i][i_];
         for(i_=0;i_<=nvars-1;i_++)
            tmp[i_]=tmp[i_]-ct[xyc[i]][i_];
         //--- calculation
         v=0.0;
         for(i_=0;i_<=nvars-1;i_++)
            v+=tmp[i_]*tmp[i_];

Não é mais simples assim?

v=0.0;
for(i_=0;i_<=nvars-1;i_++){
   tmp=xy[i][i_]-ct[xyc[i]][i_];
   v+=tmp*tmp;
}

Parece-me que a velocidade de execução seria ainda mais rápida.

Porque é que tornaram o código tão complicado? Ou apenas portado de outra língua, sem quaisquer ajustes? Mas ainda me pergunto porquê uma tal complicação no original?
1...221322142215221622172218221922202221222222232224222522262227...3184
Novo comentário