If we rephrase the problem as "how often MQL5 code is called from the terminal kernel", then everything should be measured wrong:
We should remove all unnecessary MQL5 code and leave a couple of counters in one bare function to minimise the cost of the measurement itself
Find a suitable OnXXXX entry point and a method of forced generation of calls from the kernel. Here we need to make a separate test build for metering.
In this case, having built a polygon, you can really measure all the overheads on MQL5 calls and get an interesting characteristic. As is our custom, then optimise everything several times.
This is an interesting task and we will deal with it.
If we rephrase the problem as "how often MQL5 code is called from the terminal kernel", then everything should be measured wrong:
We should remove all unnecessary MQL5 code and leave a couple of counters in one bare function to minimise the cost of the measurement itself
Find a suitable OnXXXX entry point and a method of forced generation of calls from the kernel. Here we need to make a separate test build for metering.
In this case, having built a polygon, you can really measure all the overheads on MQL5 calls and get an interesting characteristic. As is our custom, then optimise everything several times.
This is an interesting task and we will do it.
Thank you for not leaving such geeky things without attention!
Probably, we need a separate build for measuring the speed of arrival of quote packets. Just what I wanted to measure.
if through OrderSendAsync send two limiters (BuyLimit1_price < BuyLimit2_price) inside the spread, will the exchange generate two consecutive ticks with bid-price improvement at the same time (with 1ms accuracy)?
Let me explain what this will do.
When BuyLimit1 is sent inside the spread, a tick will come to us from the exchange with the time of its birth (it will generate a new Bid). After BuyLimit2 - another tick with its birth time. The difference of these two times is the speed characteristic of MT5 trading orders delivery to the exchange.
In order to make minimal monetary losses from such an experiment, you can send not two BuyLimits asynchronously, but BuyLimit and SellLimit inside the spread and choose some poorly liquid trading instrument.
The thing is that you get transaction confirmation immediately, but full transaction details arrive asynchronously after that. It can take from 0 to N ms, usually within 1-2 ms (depends on ping of course).
Because of this circumstance, the comparison with QLUA is not in favour of MT5.
fxsaber: Because of this circumstance, it is necessary to slightly adjust the comparison with QLUA not in favour of MT5.
There is no need to adjust anything. My phrase was for the general case "in your internet and your ping can be anything and in reality depending on your network you will get a transaction in 0-N ms". And it's more likely to be 0 ms than more.
Here is the verification code with control of all transactions in asynchronous mode:
ulong ExtTicks=0;
//+------------------------------------------------------------------+//| Expert initialisation function|//+------------------------------------------------------------------+intOnInit()
{
//--- output the ping to the trade server in millisecondsPrintFormat("AsyncTradesTest: last ping %.2f ms, build %d",TerminalInfoInteger(TERMINAL_PING_LAST)/1000.0,TerminalInfoInteger(TERMINAL_BUILD));
//---return(INIT_SUCCEEDED);
}
//+------------------------------------------------------------------+//||//+------------------------------------------------------------------+voidOnTradeTransaction(constMqlTradeTransaction &trans,
constMqlTradeRequest &request,
constMqlTradeResult &result)
{
Print(EnumToString(trans.type)," ",trans.symbol,": ",trans.price," ",result.order," time: ",(GetMicrosecondCount()-ExtTicks)/1000.0," ms");
}
//+------------------------------------------------------------------+//| Expert tick function|//+------------------------------------------------------------------+voidOnTick()
{
staticbool started=false;
//--- run the series once on the first tickif(!started)
{
started=true;
//--- fill in the enquiryMqlTradeRequest req={};
MqlTradeResult res={};
req.volume =1;
req.symbol =_Symbol;
req.price =SymbolInfoDouble(_Symbol,SYMBOL_ASK);
req.sl =0;
req.tp =0;
req.deviation =100;
req.type_filling=ORDER_FILLING_RETURN;
req.action =TRADE_ACTION_DEAL;
req.type =ORDER_TYPE_BUY;
req.magic =2016;
//--- run the operation loop
ExtTicks=GetMicrosecondCount();
Print("Start...");
OrderSendAsync(req,res);
}
}
2016.09.1418:32:53.234 Test (BR-12.16,H1) TRADE_TRANSACTION_HISTORY_ADD BR-12.16: 0.00 time: 11.455 ms
2016.09.1418:32:53.232 Test (BR-12.16,H1) TRADE_TRANSACTION_DEAL_ADD BR-12.16: 47.130 time: 8.778 ms
2016.09.1418:32:53.231 Test (BR-12.16,H1) TRADE_TRANSACTION_ORDER_DELETE BR-12.16: 0.00 time: 8.457000000000001 ms
2016.09.1418:32:53.231 Test (BR-12.16,H1) TRADE_TRANSACTION_ORDER_UPDATE BR-12.16: 0.00 time: 8.202999999999999 ms
2016.09.1418:32:53.231 Test (BR-12.16,H1) TRADE_TRANSACTION_REQUEST : 0.044326441 time: 8.151 ms
2016.09.1418:32:53.228 Test (BR-12.16,H1) TRADE_TRANSACTION_ORDER_UPDATE BR-12.16: 0.00 time: 5.196 ms
2016.09.1418:32:53.228 Test (BR-12.16,H1) TRADE_TRANSACTION_REQUEST : 0.044326441 time: 5.171 ms
2016.09.1418:32:53.227 Test (BR-12.16,H1) TRADE_TRANSACTION_ORDER_ADD BR-12.16: 0.00 time: 4.184 ms
2016.09.1418:32:53.223 Test (BR-12.16,H1) Start...
2016.09.1418:32:49.753 Test (BR-12.16,H1) AsyncTradesTest: last ping 2.15 ms, build 1417
You should read it from bottom to top.
It shows all stages of transactions with the cumulative total of time spent from the start. By transaction types you can see what was added to the terminal and when.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
If we rephrase the problem as "how often MQL5 code is called from the terminal kernel", then everything should be measured wrong:
In this case, having built a polygon, you can really measure all the overheads on MQL5 calls and get an interesting characteristic. As is our custom, then optimise everything several times.
This is an interesting task and we will deal with it.
I got it!Yes, we do.
Sorry, I overlooked it.
If we rephrase the problem as "how often MQL5 code is called from the terminal kernel", then everything should be measured wrong:
In this case, having built a polygon, you can really measure all the overheads on MQL5 calls and get an interesting characteristic. As is our custom, then optimise everything several times.
This is an interesting task and we will do it.
Thank you for not leaving such geeky things without attention!
Probably, we need a separate build for measuring the speed of arrival of quote packets. Just what I wanted to measure.
Please do another MT5 speed test on a real account
Forum on trading, automated trading systems and testing trading strategies
Testing 'CopyTicks'
fxsaber, 2016.09.13 11:11 AM
if through OrderSendAsync send two limiters (BuyLimit1_price < BuyLimit2_price) inside the spread, will the exchange generate two consecutive ticks with bid-price improvement at the same time (with 1ms accuracy)?
Let me explain what this will do.
When BuyLimit1 is sent inside the spread, a tick will come to us from the exchange with the time of its birth (it will generate a new Bid). After BuyLimit2 - another tick with its birth time. The difference of these two times is the speed characteristic of MT5 trading orders delivery to the exchange.
In order to make minimal monetary losses from such an experiment, you can send not two BuyLimits asynchronously, but BuyLimit and SellLimit inside the spread and choose some poorly liquid trading instrument.
Before comparing, we need to "finish" the whole complex of trading operations
(receiving data, justification of transactions, receiving confirmation of transactions).
Added Build 1395, real
Forum on trading, automated trading systems and testing of trading strategies
FORTS. Questions on execution
Renat Fatkhullin, 2016.08.23 16:35
You just need to wait 5-10 ms and try again.
The thing is that you get transaction confirmation immediately, but full transaction details arrive asynchronously after that. It can take from 0 to N ms, usually within 1-2 ms (depends on ping of course).
Before comparing, we need to "finish" the whole complex of trading operations
(receiving data, justification of transactions, receiving confirmation of transactions).
Added Build 1395, real
Just did a similar operation manually: 11.7 ms
You do not want to see the real report, but use your own glitchy method of measuring transaction time.
And you do not want to admit your mistakes, preferring to believe monstrous figures from your erroneous script.
I have just made a similar operation manually: 11.7 ms.
What are you talking about, Renate?
This is an excerpt from Temninal's log, not my own log!
Because of this circumstance, it is necessary to slightly adjust the comparison with QLUA not in favour of MT5.
There is no need to adjust anything. My phrase was for the general case "in your internet and your ping can be anything and in reality depending on your network you will get a transaction in 0-N ms". And it's more likely to be 0 ms than more.
Here is the verification code with control of all transactions in asynchronous mode:
Here is its output on a real account just now:
You should read it from bottom to top.
It shows all stages of transactions with the cumulative total of time spent from the start. By transaction types you can see what was added to the terminal and when.
The total time is 11.45 ms.