MT5 and speed in action - page 7

New comment
 
fxsaber:

You don't understand anything. When we do return, we are entering the On-functions of the generated queue. This may cause a pause which prevents the first OrderSend from sending the correct second one.

What is the pause/delay in? In the copying of 3 structures?

OnTradeTransaction( параметры )
{
        поместить параметры в очередь
        OnMain();
}

You propose to accumulate the queue by saving all the On-functions after return, waiting for the On-function, which will say that the first OrderSend is finished. And then only send the second OrderSend.

It is not necessary to accumulate all events. Don't wait for the next event to copy - you can process events before return and send the second OrderSend as soon as prerequisites arrive for this

You also do not realize that the take position can be executed during the first OrderSend, but its OnTradeTransaction will be in the queue later (in the same microsecond, but later) than the final OnTradeTransaction from the first OrderSend.

And how does it help you in such a situation?

bool HandleNextEvent(ENUM_EVENT_TYPE);

It will be last here as well as there

 
fxsaber:

You don't understand anything. When we do return, we are entering the On-functions of the generated queue. This may cause a pause which prevents the first OrderSend from sending the correct second one immediately after the first one.

You propose to accumulate the queue by saving all On-functions after return, waiting for the On-function, in which there will be a message about end of the first OrderSend. And then only send the second OrderSend.

At the same time you don't understand that the take position can be executed during the first OrderSend, but its OnTradeTransaction will be in the queue later (in the same microsecond, but later) than the finishing OnTradeTransaction from the first OrderSend.

There is no queue. The new event will be processed after the current one, and all events that occurred during this period will be ignored.

 
The queue, or stack, is formed by you, MQ does not do this.
 

In my opinion, the solution to the problem would be to be able to "subscribe" to an order. That is, for the terminal to generate an event when a transaction on an order occurs.

But this should be implemented by the developers, not by us. All of our solutions, one way or another, will return to the history of deals. I don't have such a microsecond criticality, but it's really

But it is really annoying to write complex bikes to find out if a deal is passed or not passed, if levels are triggered or if someone has corrected a position in the terminal.

Although it would seem a simple thing - an event on a trade on a position - and everything would be much easier.

 
Maksim Emeliashin:

But it is up to the developers to implement this, not us.

Developers should only provide the tools. MQL is essentially a low-level programming language (just like C++). You use it not in terms of tasks but in terms of calculations. And you make all the high-level decisions by yourself. You may lack tools, but not ready-made solutions

 
A100:

What's the pause\delay? In copying 3 structures?

In processing a queue of diverse events.

How would it help you in such a situation?

It'll be the last one here or there.

I'll be aware of the close on the take.

 
Алексей Тарабанов:

There is no queue. The new event will be processed after the current event and all events that occurred during this period will be ignored.

Incompetent.

 
fxsaber:

There are various events in the queue to be processed.

I'll be aware of the close on the tee.

Let's stop at the fact that I really (without code withHandleNextEvent ) don't understand elementary things.

As a final note, the difference between the proposedHandleNextEvent and what I wrote is that it's via recursion and I have it via a loop. Besides, the queue is initially formed and you can manage it ... you handle some events at once and postpone them for some other time, you have complete freedom.

 
What is the reason for this EA not alerts? 
const MqlTick GetMarketWatchTick( void )
{
  MqlTick Tick = {0};
  
  ::SymbolInfoTick(_Symbol, Tick);
  
  return(Tick);
}

const MqlTick GetLastHistoryTick()
{
  MqlTick Tick[1];
  
  ::CopyTicks(_Symbol, Tick, COPY_TICKS_ALL, 0, 1);
  
  return(Tick[0]);
}

void OnTick()
{
  if (GetMarketWatchTick().time_msc > GetLastHistoryTick().time_msc) // Тик из Обзора рынка свежее, чем последний тик из истории.
    Alert("Hello!");
}


At the same time, the same check, sewn into the combat trading advisor on the same Terminal, Alert. What could be the reason?

 

Forum on trading, automated trading systems and trading strategy testing

MT5 and Speed in Action

Anton, 2020.05.29 16:21

Script for testing of maximum and average time:

2474.

        Last tick time. Selected orders: 0; max time: 0.187 ms; avr time: 0.022 ms; 100000 iterations
        Last 3 days. Selected orders: 1956; max time: 1.832 ms; avr time: 0.301 ms; 100000 iterations
        Orders total: 56561

It has become very good. If you have changed it - Thank you. I'll keep an eye on the performance in combat mode.


PS In combat mode, when trades are made, it almost always lags (only outputs cases greater than 5 milliseconds).

2020.06.03 13:57:27.895 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 14 ms.
2020.06.03 13:57:47.780 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 5 ms.
2020.06.03 14:03:49.844 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 9 ms.
2020.06.03 14:03:51.063 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 8 ms.
2020.06.03 14:03:55.115 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 12 ms.
2020.06.03 14:03:56.935 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 6 ms.

Otherwise seems to be much better than 2470.

1234567891011121314...94
New comment
Reason: