Start making a demo mt5 account with bx. You will receive an email with a link to the distribution. At the server selection stage you choose not a demo server, but for real trading. Create an account with arbitrary data. Create a certificate. All you have a real account with zero balance with real quotes and history.
Start making a demo mt5 account with bx. You will receive an email with a link to the distribution. At the server selection stage you choose not a demo server, but for real trading. Create an account with arbitrary data. Create a certificate. All you have a real account with zero balance with real quotes and history.
Cool - it worked, thank you! Heaven and earth - tick data of demo and real. Thanks again!
In the "based on real ticks" mode the positive slippage of limit orders is about 50% higher than in the "based on generated ticks" mode.
This results in a mishap - we introduced real ticks to increase the accuracy of the tester, but introduced positive slippage of limit orders, artificially hovering over the backtest results.
On the exchange, limit orders do not slip, but are executed exactly at the order price. But this is not the case in the tester.
This bug can be avoided using the library described in the link above. But this is a crutch solution. It makes sense when the tester itself works accurately.
I'm asking forum members for their opinions on this subject. Since, for obvious reasons, the opinion of one member of the community is poorly taken seriously by the developers.
This topic has already been discussed here on the forum somewhere and the developers themselves seem to have said they'll fix it in the new builds. Try to look for it, I didn't really get into it...
P.s. Here's a topic that was also unanswered https://www.mql5.com/ru/forum/86591/page4.
This topic has already been discussed here on the forum somewhere and the developers themselves seem to have said they'll fix it in new builds. Try to look for it, I didn't really get into it...
P.s. Here was a topic, also unanswered https://www.mql5.com/ru/forum/86591/page4
MR 016:47:50.960 Tester RTS-9.16: ticks data begins from 2016.08.0100:00
LE 016:47:50.963 Core 1 agent process started
CE 016:47:51.473 Core 1 connecting to 127.0.0.1:3000
NR 016:47:52.736 Core 1 connected
DJ 016:47:52.741 Core 1 authorized (agent build 1401)
RR 016:47:52.743 Tester RTS-9.16,M1 (BCS-MetaTrader5): testing of Experts\LimitsFill.ex5 from 2016.08.1100:00 to 2016.08.1700:00
GP 016:47:52.763 Core 1 common synchronization completed
DI 016:47:52.780 Core 1 RTS-9.16: ticks synchronized already [47 bytes]
IL 016:47:53.493 Core 11482 bytes of tester parameters loaded
PH 016:47:53.493 Core 1188 bytes of input parameters loaded
OR 016:47:53.493 Core 18562 bytes of symbols list loaded
MI 016:47:53.493 Core 1 expert file added: Experts\LimitsFill.ex5. 8164 bytes loaded
FR 016:47:53.493 Core 1 initial deposit 100000.00 RUR, leverage 1:0
EI 016:47:53.493 Core 1 successfully initialized
IS 016:47:53.493 Core 135 Kb of total initialization data received
QJ 016:47:53.493 Core 1 Intel Core i7-2700 K @ 3.50 GHz, 16301 MB
LR 016:47:53.493 Core 1 RTS-9.16: symbol to be synchronized
PF 016:47:53.493 Core 1 RTS-9.16: symbol synchronized, 3224 bytes of symbol info received
RJ 016:47:53.493 Core 1 RTS-9.16: load 31 bytes of history data to synchronize in 0:00:00.000
PM 016:47:53.493 Core 1 RTS-9.16: history synchronized from 2015.06.22 to 2016.09.01
IS 016:47:53.493 Core 1 RTS-9.16: ticks synchronization started
JD 016:47:53.493 Core 1 RTS-9.16: load 38 bytes of tick data to synchronize in 0:00:00.000
NO 016:47:53.493 Core 1 RTS-9.16: history ticks synchronized from 2016.08.01 to 2016.09.01
RI 016:47:53.493 Core 1 RTS-9.16,M1: history cache allocated for610971 bars and contains 43890 bars from 2015.06.2210:02 to 2016.08.1023:49
CM 016:47:53.493 Core 1 RTS-9.16,M1: history begins from 2015.06.2210:02
DD 016:47:53.493 Core 1 RTS-9.16,M1 (BCS-MetaTrader5): generating based on real ticks
ML 016:47:53.493 Core 1 RTS-9.16,M1: testing of Experts\LimitsFill.ex5 from 2016.08.1100:00 to 2016.08.1700:00 started
LQ 316:47:53.493 Core 1 RTS-9.16 : real ticks begin from 2016.08.0100:00:00
GK 016:47:53.493 Core 12016.08.1119:12:33 buy limit 1.00 RTS-9.16 at 95090 (95260 / 95270 / 95270)
EK 016:47:53.493 Core 12016.08.1119:40:17 order [#2 buy limit 1.00 RTS-9.16 at 95090] triggered
GJ 016:47:53.493 Core 12016.08.1119:40:17 deal #2 buy 1.00 RTS-9.16 at 95050 done (based on order #2) GR 016:47:53.493 Core 12016.08.1119:40:17 deal performed [#2 buy 1.00 RTS-9.16 at 95050]
GP 016:47:53.493 Core 12016.08.1119:40:17 order performed buy 1.00 at 95050 [#2 buy limit 1.00 RTS-9.16 at 95090]
QR 016:47:53.493 Core 12016.08.1618:44:02 sell limit 1.00 RTS-9.16 at 97070 (97020 / 97030 / 97020)
GF 016:47:53.493 Core 12016.08.1619:00:00 order [#3 sell limit 1.00 RTS-9.16 at 97070] triggered
CG 016:47:53.493 Core 12016.08.1619:00:00 deal #3 sell 1.00 RTS-9.16 at 97170 done (based on order #3) FJ 016:47:53.493 Core 12016.08.1619:00:00 deal performed [#3 sell 1.00 RTS-9.16 at 97170]
DO 016:47:53.493 Core 12016.08.1619:00:00 order performed sell 1.00 at 97170 [#3 sell limit 1.00 RTS-9.16 at 97070]
KR 016:47:53.493 Core 1 final balance 102788.71 RUR
IF 016:47:53.493 Core 1 RTS-9.16,M1: 1122105 ticks, 3240 bars generated. Test passed in 0:00:00.717 (including ticks preprocessing 0:00:00.124).
JE 016:47:53.493 Core 1252 Mb memory used including 35 Mb of history data, 64 Mb of tick data
KK 016:47:53.493 Core 1log file "C:\Program Files\BCS Broker MetaTrader 5 Terminal\Tester\Agent-127.0.0.1-3000\logs\20160902.log" written
DJ 016:47:53.507 Core 1 connection closed
Slippage of limit orders is marked in bold. The slippage in the tester is worse when a Limit order slips through the session - at opening. But I didn't take these cases as an example. I took the usual market.
Is it reproducible?
Unfortunately, the debugging doesn't work, so it was not convenient to create the example.
Slippage of limit orders is marked in bold. The slippage in the tester is the highest when a Limit order slips through the session - at opening. But I didn't take these cases as an example. I took the usual market.
Is it reproducible?
Unfortunately, the debugging does not work, so it was not convenient to create an example
Try it not in the tester, but in demo (better Opening, it has higher speed).
Start making a demo mt5 account with bx. You will receive an email with a link to the distribution. At the server selection stage you choose not a demo server, but for real trading. Create an account with arbitrary data. Create a certificate. All you have a real account with zero balance with real quotes and history.
Start making a demo mt5 account with bx. You will receive an email with a link to the distribution. At the server selection stage you choose not a demo server, but for real trading. Create an account with arbitrary data. Create a certificate. All you have a real account with zero balance with real quotes and history.
In the "based on real ticks" mode the positive slippage of limit orders is about 50% higher than in the "based on generated ticks" mode.
This results in a mishap - we introduced real ticks to increase the accuracy of the tester, but introduced positive slippage of limit orders, artificially hovering over the backtest results.
On the exchange, limit orders do not slip, but are executed exactly at the order price. But this is not the case in the tester.
This bug can be avoided using the library described in the link above. But this is a crutch solution. It makes sense when the tester itself works accurately.
I'm asking forum members for their opinions on this subject. Since, for obvious reasons, the opinion of one member of the community is poorly taken seriously by the developers.
It's a pity that no one had a say in it.
This topic has already been discussed here on the forum somewhere and the developers themselves seem to have said they'll fix it in the new builds. Try to look for it, I didn't really get into it...
P.s. Here's a topic that was also unanswered https://www.mql5.com/ru/forum/86591/page4.
This topic has already been discussed here on the forum somewhere and the developers themselves seem to have said they'll fix it in new builds. Try to look for it, I didn't really get into it...
P.s. Here was a topic, also unanswered https://www.mql5.com/ru/forum/86591/page4
It's a shame no one spoke up.
Because you have no evidence base whatsoever.
It's much easier to save the report and zip it up. Show me an example of one transaction with the calculations.
Because you have no evidence base whatsoever.
It's much easier to save the report and zip it up. Show an example of a single transaction with a statement.
Thought that would be enoughhttps://www.mql5.com/ru/code/16134.
Got it. I'll prepare it.
Adviser
Tester Log
Slippage of limit orders is marked in bold. The slippage in the tester is worse when a Limit order slips through the session - at opening. But I didn't take these cases as an example. I took the usual market.
Is it reproducible?
Unfortunately, the debugging doesn't work, so it was not convenient to create the example.
Forum on trading, automated trading systems and strategy testing
Bugs, bugs, questions
fxsaber, 2016.09.01 20:18
Adviser
Tester Log
Slippage of limit orders is marked in bold. The slippage in the tester is the highest when a Limit order slips through the session - at opening. But I didn't take these cases as an example. I took the usual market.
Is it reproducible?
Unfortunately, the debugging does not work, so it was not convenient to create an example