MT5 : ticks data questions, issues and bugs. All about ticks. - page 2

 
Alain Verleyen: Thanks for your input. It was on MT4 I suppose ?

Anyway, it could be the reason but my concern is not about OHLC tick volume, but about real ticks. I want to know if I get all the real historical ticks or not. If the OHLC tick volume was changed I want to know why, as taken into account the above data, I have around 500,000 additional ticks and when you are working on strategy relying on ticks it matters. How can we be sure it's not an MT5 bug ?

Something tells me you will never get a satisfactory answer to this! Whether it is a bug or broker manipulation, neither party is going to address the issue because it is not in their best interest to correct it.

Probably the only option available to you will be to adjust your strategy or your code to cope with it in the best way you can, hoping for the best but planning for the worst!

One observation that is in your favour, however, is the fact that there were more ticks in the historical data than the number of ticks counted in the OHLC tick volume. Had it been the other way round, then it would really have been a severe problem.

Another point which you can investigate is to harvest tick data in real-time for a few days or even weeks and then compare it to historic tick data (by clearing bases and re-downloading it again), to see what discrepancies there are between the two, and then adjust your project to work around that issue should there be problems with this.

 
Fernando Carreiro:

Something tells me you will never get a satisfactory answer to this! Whether it is a bug or broker manipulation, neither party is going to address the issue because it is not in their best interest to correct it.

Probably the only option available to you will be to adjust your strategy or your code to cope with it in the best way you can, hoping for the best but planning for the worst!

One observation that is in your favour, however, is the fact that there were more ticks in the historical data than the number of ticks counted in the OHLC tick volume. Had it been the other way round, then it would really have been a severe problem.

Another point which you can investigate is to harvest tick data in real-time for a few days or even weeks and then compare it to historic tick data (by clearing bases and re-downloading it again), to see what discrepancies there are between the two, and then adjust your project to work around that issue should there be problems with this.

Thanks. I will publish any news about this issue.
 
Alain Verleyen: Thanks. I will publish any news about this issue.

Due to a question from a poster on another thread, I was reminded that the broker may not be getting all their data from the same source.

Maybe the reason for the differences may be that the tick data is coming from the Liquidity Provider but the OHLC may be coming from a separate Data Feed Provider and thus causing the mismatch.

 
Fernando Carreiro:

Due to a question from a poster on another thread, I was reminded that the broker may not be getting all their data from the same source.

Maybe the reason for the differences may be that the tick data is coming from the Liquidity Provider but the OHLC may be coming from a separate Data Feed Provider and thus causing the mismatch.

I remember trying to filter data by creating my own custom symbols. It seemed to me that there's a database for every time frame or, at least, ticks based and OHLC databases are different. Is that true?

 
Arthur Albano:

I remember trying to filter data by creating my own custom symbols. It seemed to me that there's a database for every time frame or, at least, ticks based and OHLC databases are different. Is that true?

No. :-D
 
Fernando Carreiro:

Due to a question from a poster on another thread, I was reminded that the broker may not be getting all their data from the same source.

Maybe the reason for the differences may be that the tick data is coming from the Liquidity Provider but the OHLC may be coming from a separate Data Feed Provider and thus causing the mismatch.

An other thing to check. Thanks again :-)
 

Arthur Albano: I remember trying to filter data by creating my own custom symbols. It seemed to me that there's a database for every time frame or, at least, ticks based and OHLC databases are different. Is that true?

Alain Verleyen: No. :-D

Actually @Arthur Albano is indeed (mostly) correct! On MetaTrader 5 the OHLC and the Tick data are separate and distinct. OHLC data are build up from ".hcc" files under the "history" sub-folder (but not for every time-frame as that is cache based) and the tick data is build up from ".tkc" files under the "ticks" sub-folder respectively (and this is indeed how Custom Symbols are build up too, separate OHLC and Ticks databases).

If this were not the case, then it would indeed have been a major bug for you to have this difference in tick volume between the two in your testing. There are indeed two separate databases in MetaTrader 5 for OHLC Data and Tick Data.

This however does not excuse the fact that the tick count is different and in my opinion in should never have been allowed for it to be different, but that is something else entirely.

 

Do you realize that 87265.500@19:30:00.053 is plain wrong? The market closes at 18:00, and yet seems limit orders are being placed between 18:00 and 19:30 (after market?). But one broker filters out this absurd value, while other does not. So, in the end, data checking and filtering is always recommended, and I do it.

I will question both broker about this issue and if they apply filtering or not. Broker behaviour is important for me. Not counting differences. :D (I still count numbers with fingers carefully for procedural programming) :P



 
Arthur Albano:

Do you realize that 87265.500@19:30:00.053 is plain wrong? The market closes at 18:00, and yet seems limit orders are being placed between 18:00 and 19:30 (after market?). But one broker filters out this absurd value, while other does not. So, in the end, data checking and filtering is always recommended, and I do it.

I will question both broker about this issue and if they apply filtering or not. Broker behaviour is important for me. Not counting differences. :D (I still count numbers with fingers carefully for procedural programming) :P



Is this broker server use the same time as Bovespa ? (same timezone ? just an idea to explain it).

I just noticed you used WDO$, which is continuous symbol which is not directly tradable, not sure it's the best way to check ticks (?).

These are DOM ticks which was not discussed (yet) by me on this topic. Anyway, I checked WDOZ18. Broker X, real account and all is normal on that matter (though milliseconds timestamps are not delivered).

WDO$ is NOT giving the same data (only "Last" ticks).

 
Alain Verleyen:

Is this broker server use the same time as Bovespa ? (same timezone ? just an idea to explain it).

I just noticed you used WDO$, which is continuous symbol which is not directly tradable, not sure it's the best way to check ticks (?).

These are DOM ticks which was not discussed (yet) by me on this topic. Anyway, I checked WDOZ18. Broker X, real account and all is normal on that matter (though milliseconds timestamps are not delivered).

WDO$ is NOT giving the same data (only "Last" ticks).

Instrument: WDOZ18. Broker M:

Broker R doesn't have ticks after market close:


At 18:00 (theoretical(?) market close):

Broker M:



Broker R:


Broker R fails Boyce-Codd, or it's simply not displaying ticket number (primary key), for instance. Ticks report does not have column display options.

Reason: