Errors, bugs, questions - page 2220

 
1861 - impossible to open a demo on Alpari. Choosing a broker does not work.
 
fxsaber:

In my opinion, this is a bug when an order is on the trade server, but after the synchronous OrderSend on the terminal there is no sign of it.

I have decided to check how long such phantom orders last when the order is present on the system but not in the 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;
}


The result is

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


An order is present in the system but not in the Terminal for 32 milliseconds! Just imagine the consequences if the trading logic was executed in this interval ...


It is interesting that phantom orders are most often present only atTRADE_TRANSACTION_ORDER_DELETE and at TRADE_TRANSACTION_DEAL_ADD (much rarer) transaction types.


Very bad platform nuance.


ZZY The speed of trade transactions on 5 is questionable, unfortunately.

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

I decided to check how long such phantom order situations last, when an order is in the system but not in the terminal.


The result is


For 32 milliseconds, there is an order but it is not in the Terminal! Just imagine the consequences if the trading logic was executed during this interval.

Yeah, that's not good. As you can see, these transaction results are sent in different packets. They should be in one.

 
Alexey Navoykov:

As you can see, these transaction results are sent in different packages, while they should be in one.

It turns out that the order can be phantom right after OrderSend and the parallel Expert Advisor with OnTradeTransaction cannot always catch this state. I.e. OnTradeTransaction itself sometimes slows down.


Generally speaking, there are lags in MT5 architecturally in different places which are hardly eliminated. These are lags of tick arrivals and now of trade transactions. You need to be clear about what the platform is capable of if you are banking on execution speed. For example, ticks coming in with a decent delay, then transactions... and eventually someone else on MT5 or another platform can overtake, even if you yourself are sitting right next to the exchange.

 
Trade transactions go in priority packets, overtaking the rest. This seriously reduces latency.
 
Renat Fatkhullin:
The trade transactions go in priority packets, overtaking the others. This seriously reduces latency.

How is it possible that the script detects a phantom order situation after OrderSend, but OnTradeTransaction on a parallel EA does not (not always, but it happens)?

 
Renat Fatkhullin:
The trade transactions come in priority packets, overtaking the others. This seriously reduces latency.

The problem is thatTRADE_TRANSACTION_ORDER_DELETE andTRADE_TRANSACTION_HISTORY_ADD transactions come in different packets and that's why it doesn't matter which priority they have, network latency will anyway.And these transactions must be executed synchronously, one after another, without any intermediate state. I.e. it's one atomic operation in essence, because putting a deleted order into history list has nothing to do with an exchange.

I.e. there are two options here: either these two transactions come together in one package, or the first transaction is not executed in the terminal until the second arrives.

 
Alexey Navoykov:

I.e. there are two options: either both transactions come together in one package, or the first transaction is not executed in the terminal until the second one arrives.

There are situations when TRADE_TRANSACTION_DEAL_ADD comes BEFORE the TRADE_TRANSACTION_ORDER_DELETE transaction. In this case even before TRADE_TRANSACTION_ORDER_DELETE the order is still phantom.

 

Remote agents have stopped optimising

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

I assume it's because of the new compiler, how can they be updated to make it work?

Also, only part of the optimiser passes 13 out of 28 because of this error.
 

Looking through the code of the Alglib package. It's full of these constructions, making the code more difficult to read:

         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_];

Isn't it simpler like this?

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

It seems to me that the execution speed would be even faster.

Why did they make the code so complicated? Or just ported from another language, without any adjustments? But I still wonder why such a complication in the original?
Reason: