Discussion of article "MQL5 vs QLUA - Why trading operations in MQL5 are up to 28 times faster?" - page 3

New comment
 
Renat Fatkhullin:

Simultaneously, it is when you have a difference in measurements floating like 10%.

But when according to the results of dozens of tests you have a stable difference of 4-5 times, there is nothing to discuss.

The difference (not stable) on MT5 was up to two times. That's why I decided that if we measure performance, we should look at the maximum frequency (minimum time between neighbouring packets) with which packets arrive. I wrote a corresponding Expert Advisor

class FREQUENCY
{
private:
  ulong PrevTime;
  int MinInterval;
  datetime TimeMinInterval;

  static string ToString( const int Interval, const datetime ServerTime )
  {
    return("Frequency = " + ((Interval == 0) ? "Unknown" : ::DoubleToString(1 e6 / Interval, 1)) +
           " Hz (" + ::DoubleToString(Interval / 1000.0, 3) + " ms), ServerTime = " + (string)ServerTime);
  }

public:
  const string symbol;

  FREQUENCY( const string Symb = NULL ) :
         symbol((Symb == NULL) ? ::Symbol() : Symb), MinInterval(INT_MAX), PrevTime(0)
  {
  }

  ~FREQUENCY( void )
  {
    ::Comment("");
  }

  void Refresh( const string Symb )
  {
    if (Symb == this.symbol)
    {
      const ulong NowTime = ::GetMicrosecondCount();

      if (this.MinInterval == INT_MAX)
        this.MinInterval--;
      else
      {
        const int Interval = (int)(NowTime - this.PrevTime);

        if (Interval < this.MinInterval)
        {
          this.MinInterval = Interval;
          this.TimeMinInterval = ::TimeCurrent();

          ::Alert(this.ToString());
        }

        ::Comment(FREQUENCY::ToString(Interval, ::TimeCurrent()) + "\n" + this.ToString());
      }

      this.PrevTime = NowTime;
    }

    return;
  }

  string ToString( void ) const
  {
    return("Max" + FREQUENCY::ToString(this.MinInterval, this.TimeMinInterval) +
           ", ServerName = " + ::AccountInfoString(ACCOUNT_SERVER) + ", Symbol = " + this.symbol);
  }
};

class FREQUENCY_BOOK : public FREQUENCY
{
public:
  FREQUENCY_BOOK( const string Symb = NULL ) : FREQUENCY(Symb)
  {
    ::MarketBookAdd(this.symbol);
  }

  ~FREQUENCY_BOOK( void )
  {
    ::MarketBookRelease(this.symbol);
  }
};
/*
FREQUENCY Frequency;

void OnTick( void )
{
 Frequency.Refresh(_Symbol);

 return;
}
*/

FREQUENCY_BOOK FrequencyBook;

void OnBookEvent( const string &symbol )
{
  FrequencyBook.Refresh(symbol);

  return;
}

And got the result

2016.09.14 10:21:47.059 Frequency (Si-9.16,M1)  MaxFrequency = 28571.4 Hz (0.035 ms), ServerTime = 2016.09.14 10:21:28, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:47.014 Frequency (Si-9.16,M1)  MaxFrequency = 6211.2 Hz (0.161 ms), ServerTime = 2016.09.14 10:21:28, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:40.062 Frequency (Si-9.16,M1)  MaxFrequency = 5988.0 Hz (0.167 ms), ServerTime = 2016.09.14 10:21:21, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:35.199 Frequency (Si-9.16,M1)  MaxFrequency = 1242.2 Hz (0.805 ms), ServerTime = 2016.09.14 10:21:16, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:35.149 Frequency (Si-9.16,M1)  MaxFrequency = 222.9 Hz (4.486 ms), ServerTime = 2016.09.14 10:21:16, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:34.459 Frequency (Si-9.16,M1)  MaxFrequency = 122.0 Hz (8.200 ms), ServerTime = 2016.09.14 10:21:15, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:28.640 Frequency (Si-9.16,M1)  MaxFrequency = 120.7 Hz (8.286 ms), ServerTime = 2016.09.14 10:21:09, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:25.602 Frequency (Si-9.16,M1)  MaxFrequency = 115.2 Hz (8.684 ms), ServerTime = 2016.09.14 10:21:06, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:24.572 Frequency (Si-9.16,M1)  MaxFrequency = 106.7 Hz (9.373 ms), ServerTime = 2016.09.14 10:21:05, ServerName = BCS-MetaTrader5, Symbol = Si-9.16

And if ~10ms between neighbouring BookEvent events is plausible. But 0.035ms is not. It turns out that a BookEvent event is created by the same principle as a Tick event:

The Tick-event occurs at an ultra-huge frequency:

MaxFrequency = 12820.5 Hz (0.078 ms), ServerTime = 2016.09.14 09:29:05, ServerName = RoboForexEU-MetaTrader 5, Symbol = EURUSD.e

This can only be explained by the fact that if a tick packet arrives, a Tick-event is generated for each tick from the packet at a certain interval and number (set by the developers). This way we do not miss close ticks in Expert Advisors.


As for Calculate-events, having converted the code into an indicator, the maximum frequency between Calculate-events is much higher than for Tick-events. This is due to the fact that a Calculate-event seems to be created for ALL ticks in the package.

Therefore, this measurement implementation is not suitable for Tick/Calculate/BookEvent events. And how to monitor the arrival of a new quote network packet in MQL5 is not clear yet.

 
Renat Fatkhullin:

Any test must contain protection against cold start.

So skipping N ticks is an indicator that we are aware of this fact and take it into account. Just to avoid the obviously expected "why didn't you compensate for the impact of cold start" claim.


The video about the start of the session of three terminals was prepared on 25 August 2016 for another claim of a trader who claimed that MT5 slows down at the start of the session. As it turned out later, this trader did not use MT5 at all, but broadcasted speculations from the forum. It also turned out that some traders were not aware that for exchange instruments charts are built not by Bid, but by traded Last prices. They perceived changing Bids and not showing them on charts as "MT5 brakes".

Of course, there are no brakes.

Thank you, now I understand!
 
fxsaber:

The difference (not stable) on MT5 was up to two times. So I decided that if we measure performance, we should look at the maximum frequency (minimum time between neighbouring packets) with which packets arrive. I wrote a corresponding Expert Advisor

And got the result

And if ~10ms between neighbouring BookEvent events is plausible. But 0.035ms is not. It turns out that a BookEvent is created by the same principle as a Tick event:

Plausible.

Data comes transactionally and the fact that you have seen two consecutive transactions with short timing is a great proof of the correctness of our processing and the performance of both the terminal itself and the MQL5 subsystem.


Therefore, this method of measurement is not suitable for Tick/Calculate/BookEvent events. And how to monitor the arrival of a new quote network packet in MQL5 is not clear yet.

It is very suitable.

Look at our code - it specifically measures not single short data, but stupidly collects ticks for 30 seconds. This levels out any fluctuations and any errors.

In the above video, MQL5 received 1,278 ticks in 30 seconds, while QLUA received only 254 ticks. This is a cruel bummer for QLUA algotrading.

 
Renat Fatkhullin:

Plausible.

Data come transactionally and the fact that you have seen two consecutive transactions with short timing is a great proof of the correctness of our processing and performance of both the terminal and the MQL5 subsystem.

But they came in a packet in a network packet. I want to measure the gateway speed.

It's a good fit.

Look at our code - it specially measures not single short data, but stupidly collects ticks for 30 seconds. This levels out any fluctuations and any errors.

In the above video, MQL5 received 1,278 ticks in 30 seconds, while QLUA received only 254 ticks. This is a cruel bummer for QLUA algotrading.

You have not understood my point. I don't care about QLUA-braking in any way - everything is clear with it (and there are no questions to the article). I want to get performance characteristics of MT5 itself. And just the MaxFrequency-way, as I have implemented, does not fit. Because MT5 has a peculiarity with creation of Tick/Calculate/BookEvent events. Run the Expert Advisor at your place - you will see it very quickly.
 
fxsaber:

But they came in a bundle in the network packet. I want to measure the speed of the gateway.

It doesn't matter.

Just ticks came one after another, and MT5 terminal managed to give them to you nicely and without brakes.


You misunderstand me. I don't care about QLUA-braking - everything is clear with it (and there are no questions to the article). I want to get performance characteristics of MT5 itself. And just the MaxFrequency-way, as I have implemented, does not fit. Because MT5 has a peculiarity with creation of Tick/Calculate/BookEvent events. Run the Expert Advisor at your place - you will see it very quickly.

The principle"each tick is a transaction sent independently" means that ideologically everything is built correctly. And how can it be wrong if we built 5 platforms from scratch and went through all the pitfalls more than once.

You got very high performance. The fact that you started making up the frequency is obvious nonsense. We have data when we have data when we have data. So talking about "frequency stability/instability" makes no logical sense. You are not testing the stability of the quartz oscillator, you are trying to stabilise the random process of prices appearing in the glass.

It is just Quick that originally built all the processes on the control of snapshot frequency. With a natural result.

 
Renat Fatkhullin:

It doesn't matter.

Just ticks came one after another, and MT5 terminal managed to give them to you nicely and without brakes.


The principle "each tick is a transaction sent independently" means that ideologically everything is built correctly. And how can it be wrong if we built 5 platforms from scratch and went through all the pitfalls more than once.

You got very high performance. The fact that you started making up the frequency is obvious nonsense. We have data when we have data when we have data. So talking about "frequency stability/instability" makes no logical sense. You are not testing the stability of a quartz oscillator, you are trying to stabilise the random process of prices appearing in the glass.

I can easily explain the principle of frequency. The stack is formed by the exchange itself at an unstable speed, because it depends on the actions of market participants.

I wanted to measure the maximum frequency of stack updates - how many stacks MT5 can generate per unit of time. It turned out that stakes come to MT5 in packages. It is possible that the stakes from the exchange are not even lost, but ALL of them come at all. And BookEvent event is created not for a package, but for all the stakes in the package (from the earliest to the latest). It is impossible to get the time of stack formation in MQL5. The time of package arrival is the same. Therefore, it turns out that my implementation of measuring the corresponding MT5 performance characteristic does not show what I want to see.

The fact that BookEvent is formed in packets - I support it with all my limbs. It is maximum information and minimum hassle for the Expert Advisor. The only problem with performance measurement is what I described.

 
fxsaber:

I can easily explain the principle of frequency. The stack is formed by the exchange itself at a variable rate, because it depends on the actions of market participants.

I wanted to measure the maximum frequency of stack updates - how many stacks MT5 can generate per unit of time. It turned out that stakes come to MT5 in packages. It is possible that the stakes from the exchange are not even lost, but ALL of them come at all. And BookEvent event is created not for a package, but for all the stakes in the package (from the earliest to the latest). It is impossible to get the time of stack formation in MQL5. The time of package arrival is the same. Therefore, it turns out that my implementation of measuring the corresponding MT5 performance characteristic does not show what I want to see.

The fact that BookEvent is formed in packets - I support it with all my limbs. It is maximum information and minimum hassle for the Expert Advisor. But there is only a problem with performance measurement that I described.

I repeat once again - it makes no sense to measure the frequency in this way and make such conclusions.

Do not try to measure the frequency of a random process of price appearance in the stack based on the time difference between two ticks. You will obviously get a wild scatter of numbers from 1 to XXXXX.

You have asked the wrong question, calculated incorrectly and made wrong conclusions. At the same time you put a shadow on the wicker with the statement "MT5 does not show what you want to see, you can't measure it".

There is no problem of "performance measurement", because you measured the wrong thing and in the wrong way. You came up with the wrong characteristic and fundamentally wrong calculation.


ps: but in the tests we measured the frequency of quotes arrival correctly by collecting quotes for 30 sec and dividing by the time spent.

 
Renat Fatkhullin:

I will repeat once again - it makes no sense to measure the frequency in such a way and make such conclusions.

Do not try to measure the frequency of a random process of price appearance in the glass based on the time difference between two ticks. You will obviously get a wild scatter of numbers from 1 to XXXXX.

You have asked the wrong question, calculated incorrectly and made wrong conclusions. At the same time you have cast a shadow on the wicker with the statement "MT5 does not show what you want to see, you can't measure it".

ps: but we measured the frequency of quotes arrival correctly in the tests by collecting quotes for 30 sec and dividing by the time spent.

I measure the MAXIMUM frequency, not the current one! I described in great detail the reason for such measurements, the results and gave the source. For some reason you feel that I am casting a shadow over MT5.

Any forum old-timer who reads this discussion will understand what I meant. And will see no shade towards MT5. My implementation turned out to be wrong. Mine, not yours! That you are defending yourself where I didn't even give a reason.

It is my implementation that does not allow you to measure what you want. MQL5 doesn't have such a possibility and it's normal. Just as it is normal that I want juice, but MQL5 does not provide such an opportunity.

I only shared the result that if someone wants to measure the time between the neighbouring calls of the corresponding events and interpret it as performance. It is necessary to clearly realise what will actually be shown.

 

You are fundamentally wrong.

What is the maximum frequency, when you are actually going to measure the delta of a random process, where two events have delta 0?

If the tick delivery is implemented correctly (and we have it correctly), you will obviously get the maximum "frequency" = (time of processing of MQL5 call with the programme code) / (timer error).

Theoretically, if you meet the accuracy of the timer and get 0 microseconds, the frequency will be infinity. Well and the critical error of division by zero (you have no control of division by zero in your code).

 
Renat Fatkhullin:

You are fundamentally wrong.

What is the maximum frequency, when you are actually going to measure the delta of a random process, where two events have delta 0?

If the tick delivery is implemented correctly (and we have it correctly), you will definitely get the maximum "frequency" = (time of processing of MQL5 call with the programme code) / (timer error).

Yes, that's how I get it. It turned out that I was measuring a random process, and I wanted to measure the process of network packet delivery. But it didn't work.

Theoretically, if you can meet the timer accuracy and get 0 microseconds, the frequency will be infinity. Well, and a critical division by zero error(you don't have division by zero control in your code).

Yes, I do!
1234567
New comment