GetTickCount() in tester? How to inject mili-second delays in tester... - page 3

New comment
 
You can't get millisecond delays, but you can simulate orderSend taking multiple seconds.
DateTime dropTicks;
int start() {
  if (CurTime() <= dropTicks) return(0);
  //...
  orderSend(...); dropTicks=CurTime()+MathRand()*5/32767;// 0-4 seconds
 
WHRoeder:

You can't get millisecond delays, but you can simulate orderSend taking multiple seconds. 

DateTime dropTicks;
int start() {
  if (CurTime() <= dropTicks) return(0);
  //...
  orderSend(...); dropTicks=CurTime()+MathRand()*5/32767;// 0-4 seconds

This concept has already been discussed in this thread. But what you are proposing won't work as it's supposed to.

You can only get delays quantized to the number of seconds passed between ticks. So for example if the specific M1 bar has a volume of 6, you would get ticks coming on average every 10 seconds, and that's the delay u would get in this case (which is greater than 0-4 seconds).

In order to get 1 sec accuracy in delays u need M1 bars with volume >= 60 for all bars (or M5 bars with volume >= 300, etc.). The only way to achieve this is to manipulate volume data in the HST file (which is not a problem), but IMHO I think is not worth it and will probably distort the results (not to mention make the testing much slower).

Regarding the question of milli-second delay injections - the Tester is simply not designed for it.

p.s. The code in the beginning of this thread is buggy... It counts ticks across several minutes. Proper code would show that in the Tester, the number of ticks (price changes) in a bar is the same as the volume associated with that bar (in the HST file).

 

You can only get delays quantized to the number of seconds passed between ticks.

Axactly as in the real world, you loose ticks if the EA can't keep up.

 
WHRoeder:

Axactly as in the real world, you loose ticks if the EA can't keep up.

Yes, but in the real world time is continuous, whereas in the Tester it's quantized. Specifically, in the real world a delay might end before the next tick, might be longer than several ticks, and will most likely end somewhere between two ticks. In the Tester a simulated delay can only have the exact same length as the time between tick/s, so it will always end at exactly the start of a tick. Therefore any kind of "delay" simulation in the Tester is inherently flawed and limited.

 
gordon:

As far as I can tell GetTickCount() does not work in Tester (if I'm wrong then PLEASE correct me). So my question is, how can I "inject" a delay into Tester? For example, let's I want a more realistic OrderClose() function - obviously in Live/Demo closing an order takes time - a few 100 mili-seconds. Is there a way to put this delay in the Tester? I've tried using GetTickCount() to do this, but it doesn't seem to work in Tester (and Sleep() doesn't work as mentioned in the documentation). Any way to achieve this?


Anybody know a better source of history data than downloading it from MetaQuotes in History Center (in the MT4 program)...?

Easy, I do not know why you have taken so long to find an answer to this question but I am going to give you the answer, because I also encountered this problem.
GetTickCount () and GetMicrosecondCount () as well as TimeLocal () or TimeCurrent () and many more functions will not work on the tester since data is built according to historical data.
To add the delay you want to be as faithful as possible to the reality, the answer is as easy as going from MetaEditor to: tools, options, debug and execution. Very simple, and if you need more information about what the parameters mean read the manual, with F1 you have access.

I have to tell everyone who asks questions in the forum that before saying anything they read the WHOLE manual, not pieces.

By @CapitanQwark ^u^ 


Files:
xD.png  21 kb
123
New comment