new mql4 providing millisecond in timestamps.... - page 2

 
Be aware if milliseconds and nanoseconds are so important that these ticks are coming in over the internet ( network-bound IO ). Nonosecond time resolution is probably overkill unless you are planning something naughty!
 
angevoyageur:
There is no such information in mql5 neither. But there is Timer events which can be used with milliseconds precision, though I don't know if this feature will be available with the new mql4.

The current mql4 equivalent is something like below:

void start(){
    while(true){
        do_something....;
        Sleep(1000); //Sleep for one Second.
        RefreshRates();
    }
}

void start(){
    static bool RunOnce;
    if(RunOnce) return;
    int Begin=GetTickCount();
    while(GetTickCount()<Begin+1000){
        Print("GetTickCount()="+GetTickCount());
        Sleep(1);
    }
    RunOnce=true;
}

I've tested the GTC and it seems to jump by 16_milliseconds. Come to find out, its probably some kind of Computer_Science limitation on legacy systems. If anyone would like to explain why [ despite my ramblings ] I'll be glad. Hummm, wonder if mql5 have the same limitations? Alright one more test coming right up :)

 

It is always worth effort to find out, what Widows API function the MQL developers encapsulated.

In this case the answer is easy - they used GetTickCount It says:

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

 

I've googled it before and although I don't really understand, it seems GetTickCount() is a function directly from the windows OS. It's not meant to be accurate and shouldn't be used for things that need to be accurate to the millisecond level (even though it returns values in milliseconds).

I've done tests with sleep and with get tick count and there are always errors, it's hard to tell if they are caused by Sleep or GTC but my guess is both

 
Ovo:

It is always worth effort to find out, what Widows API function the MQL developers encapsulated.

In this case the answer is easy - they used GetTickCount It says:

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Thank you.
 
ubzen:

The current mql4 equivalent is something like below:

I've tested the GTC and it seems to jump by 16_milliseconds. Come to find out, its probably some kind of Computer_Science limitation on legacy systems. If anyone would like to explain why [ despite my ramblings ] I'll be glad. Hummm, wonder if mql5 have the same limitations? Alright one more test coming right up :)

16 milliseconds limitation comes from an hardware limitation, but there is other ways to get better precision timer.
mql5 have the same limitation for GetTickCount() but as I tried to explain above there are others features that can be used (timer events).

 
Ovo:

It is always worth effort to find out, what Widows API function the MQL developers encapsulated.

In this case the answer is easy - they used GetTickCount It says:

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.


Yes that's what it says, but it's tough to know what that really means. If the resolution is 16 ms, I would expect to see values of 0,16,32,48.. etc.

I never see anything between 0 and 16 but I see every value about 16.

 
angevoyageur:

16 milliseconds limitation comes from an hardware limitation, but there is other ways to get better precision timer.
mql5 have the same limitation for GetTickCount() but as I tried to explain above there are others features that can be used (timer events).

Gotcha :)
 
RaptorUK:
Volume is a bad name for what is actually "Tick count" . . . it's nothing to do with traded volume/lots . . . the reason it can change by more than 1 is because you can miss ticks.


Thanks for the info. I wonder how didn't I notice this before. In this case, it seems quite a useless (or misleading) information.

I really have to look for real level2 volume data from some brokers. Fortunately my ECN broker offers level2 trading data with real volume.

Reason: