Tickstory

Hello!

I've a problem after conversion: the opening times of the bars in M15 timeframe are like: 20:15:02, 20:30:02, etc. Then I tried H4 timeframe: 08:02:00, 12:02:00, etc.

Maybe there is a problem in the conversion code of yours, and when you find somewhere a first tick which is not coming in at a standard time (relatively to the bar), the code will inherit that bad timing to all of the bars.

I've Windows XP Professional SP3, Hungarian version. Somewhere I read about a possible language/regional setting problem, I switched to English standards but after the re-conversion the problem is still there.

Somebody pointed out this problem in a previous topic here, you answered that the problem will be corrected in version 0.6. I used 0.7, but the problem is still here!

Thank you for your answer!

Hi radu,

Could you please outline the exact steps you are doing to get this result? This includes the symbol you are exporting, the date range and how you are viewing the exported data (CSV or MT4?).

Thanks.

Hello tickstory,

tickstory wrote: Could you please outline the exact steps you are doing to get this result? This includes the symbol you are exporting, the date range and how you are viewing the exported data (CSV or MT4?).

Sorry, I should post that information previously!

The date is 2009/01/01 - 2009/01/10, EURUSD in InstaForex terminal.

I'm using Tick Data Suite to run backtest.

I generated all timeframes in order to check what's happening.

Time setting is GMT, Casablanca - Monrovia - Instaforex's timezone in default is GMT+2.

M1: fine
M5: 00:02, 00:07, 00:12, 00:17, etc.
M15: 16:02, 16:17, 16:32, 16:47, etc.
M30: 9:02, 9:32, 10:02, 10:32, etc.
H1: 9:02, 10:02, 11:02, etc.
H4: 10:02, 14:02, 18:02, etc.
D1: fine
W1: every bar starting with Tuesdays: 2009.01.06, 2009.01.13, 2009.01.20, etc. (Maybe this is another problem, related to my timezone setting; even with GMT+1 or GMT+2 the dates are wrong: 2009/01/04, 2009/01/11, 2009/01/18 )
MN: fine

For 2010, the time slippage is 4 minutes on every bar time.

I tried EURGBP 2009/01/01 - 2009/01/10: the result was exactly the same, except 2 minutes is the time slippage instead of 2 minutes.

Generated bars for 2013 (EURUSD, and EURPLN) are perfect.

Two example screenshots:


If you need more debug info, tell me!

Hi Radu,

Thanks very much for the detailed information. The following two issues have been raised and resolved off-the-back of the details you provided:

•[TICKLITE-84] MT4 Export: Weekly/monthly bars were getting filtered when they occurred on the weekend.
•[TICKLITE-85] MT4 Export: Bar start times should start on the hour for time-frames > 1 minute.

The fixes need further testing, however since some of the issues may be disrupting some users ability to back-test (i.e. those back-testing on a weekly/monthly time-frame), a release candidate is being put up. Please find the following post on this topic:

http://www.tickstory.com/forum/viewtopic.php?f=2&t=122

Appreciate if you could give feedback if the behaviour is as you expect.

Kind regards.

Hello tickstory,

tickstory wrote: •[TICKLITE-85] MT4 Export: Bar start times should start on the hour for time-frames > 1 minute.

Thank you for your qiuck fix. It seems to be working.

The W1 timeframe however starts with 2009.01.04, 2009.01.11, 2009.01.18 wich all are Sundays. But I checked other symbols in the default Instaforex installation, and they have these dates on the W1 timeframes, so this is not a problem as far as I understand it.

MN1 timeframes are fine, too.

tickstory wrote: •[TICKLITE-84] MT4 Export: Weekly/monthly bars were getting filtered when they occurred on the weekend.

What this exactly means?


There is a bug which was in the previous version, too. When I'm trying to click on the folder selector icon inside Settings->Dukascopy Datasource tab, nothing happens. (no file selection windows is popping up, I have to manually edit the path If I would like to change it)

Great like for the regional date format, thanks! Could you modify that in the Earliest date and Last date column?

One more question: when I have already downloaded data, and click to Export the software saying "retrieving...". Is this means that TickStory Lite checks all the files again, or trying to download again, or what? When I copied previously downloaded tick data from SQ Tick Downloader (same directory structure), TSL did the downloading (or at least run-through) again, so there was no speed gain whatsoever. Is this normal, or do you want to improve this data handling in the future?

Hi Radu,

Thanks for your feedback. Will take a look into the items you mentioned and address them before the v0.8 release.
Regarding the data download, the system will always check for the presence of the data on your local disk prior to attempting to retrieve data from the web. Therefore, the data will only be downloaded once. Much of the time overhead in producing extracts is the writing of the FXT files which are usually over a gigabyte in length for each timeframe. You can speed up the process by only exporting the timeframes you intend to back-test with.
Having said this, there are speed improvements in the pipeline which involves storing the data in our own tick database format.

Hope this helps!

tickstory wrote:Regarding the data download, the system will always check for the presence of the data on your local disk prior to attempting to retrieve data from the web. Therefore, the data will only be downloaded once. Much of the time overhead in producing extracts is the writing of the FXT files which are usually over a gigabyte in length for each timeframe. You can speed up the process by only exporting the timeframes you intend to back-test with.
Having said this, there are speed improvements in the pipeline which involves storing the data in our own tick database format.

Thanks for your answer. Maybe the text "retrieving" is not always accurate; you could use downloading/converting/etc. to indicate the process. But this is only a minor suggestion!

Hi Radu,

Understand the potential confusion. At the moment the system doesnt have specific messages for internet downloads vs downloading from file hence the "retrieval" message. Will note this for future versions.

Regards.