Stupidly Good EA - worthless and I don't know what it is doing - page 2

 

Hi rush,

If you feel back test result is not real, then run it on demo account 24/7

Thanks

 

here's an insight on how StrategyTester generates the Ticks, as you can see in the interactive chart at the end of the article, the generated ticks are all over the place, not good ...

 
Humm, so Mql5 back-tester uses only ticks of one minute (just like mql4), but with 3 control points within the Test-Tick. That is if the Test-Tick had 3 or more actual ticks within the minute. Question for Senior members, does that sum-up the new back-tester? I know it's still not perfect but does it satisfy your back-tester criticism?
 

If there is no independent tracking of bid and ask prices (like MT3 did) then right off the bat you are starting out with only half the data at best. It only goes downhill from there if there is not tick history usage in MT5. What is so silly about this situation is that the data exists, it is present in real-time, and with today's hard-drive capacity there really is no valid excuse for not logging this info to an hst file. Rollover rates is another one.

 
1005phillip:

What is so silly about this situation is that the data exists, it is present in real-time, and with today's hard-drive capacity there really is no valid excuse for not logging this info to an hst file. [...]

Clients would be able to handle this with no problem (even with a very old computer), but it would be a big impact on the MT5 sever - bandwidth/server load considerations... There are several moderator comments in the forums that suggest that these are the reasons...
 

Gordon the data are already pushed from the server to the client, the work is already done by the server. All that is missing is the code/logic to log the data.

Does your passive tick logging codes increase the workload for MT5 server? Does it change their bandwidth considerations? What about the spread data? Rollover rates?

All these data are already pushed by the server to the client.

 
1005phillip:

Does your passive tick logging codes increase the workload for MT5 server? Does it change their bandwidth considerations?

Of course not; the ticks are being sent anyway, that's true...

But that's only half the picture - the majority (in terms of the time it spans) of the data pushed to the client is history data (and not ticks in real-time). That data is pushed as timeframe data (according to the opened chart / selected timeframe in the History Center) because it requires much less bandwidth and simpler server infrastructure. If that data were pushed as Tick data, then there would be a big impact on the servers (this impact translates to a cost impact for the brokers).


This is what I gathered from several moderator's comments when asked about this... These comments are in threads discussing MT5 features before it came out (when people were suggesting features, etc...).

 
ubzen:
Humm, so Mql5 back-tester uses only ticks of one minute (just like mql4), but with 3 control points within the Test-Tick. That is if the Test-Tick had 3 or more actual ticks within the minute. Question for Senior members, does that sum-up the new back-tester? I know it's still not perfect but does it satisfy your back-tester criticism?

Correction: Looks like Mql5 actually have 11 check-points within the minute-tick. I only hope this helps speed up testing, if they are taking the Open-price testing away.
 
1005phillip:

What is so silly about this situation is that the data exists, it is present in real-time, and with today's hard-drive capacity there really is no valid excuse for not logging this info to an hst file.

I'm not necessarily disagreeing with your conclusion, but there are some excuses for not doing this. It's then debatable whether or not they're valid excuses:

  • A tick data file is obviously going to be several times larger than an M1 data file. The combination of those across a few symbols could potentially start hitting the average VPS limit.
  • A copy of terminal.exe is going to have substantially higher disk I/O usage from dumping all the ticks to disk - still by no means massive, but potentially enough to affect the ability to run 10+ instances on a single low-spec VPS.
  • It's questionable whether it's worth logging the ticks without also being able to obtain historic tick data from the broker/Metaquotes server (which is more or less the point gordon is also making). For comparison, Hotspot doesn't let you download more than 4 months of data at a time because the file sizes are potentially so vast - and that's after compression.

 

All valid points jjc, but all those same reasons could be applied to eliminate M1 altogether if desired...they are arbitrary cut-off points in terms of data retention.

If metaquotes can see reason to incorporate the following options for M1 charts resource usage then surely offering the same flexibility for managing tick-based charts to the end user is within capability:



Personally I don't subscribe to the line of reasoning that this decision has anything to do with concerns over the client's computing resources or that of the broker's...to me that is a deflection argument...my personal perspective on this is that it simply has to do with the fact that no two customers are guaranteed the same price-data at the tick level even when it is coming from the same login server. And what broker wants their platform to be out-of-the-box capable of logging the very data that would make this reality-on-the-ground all the more available for analysis and characterization at later dates?

Consider the fact that the data which is not retained - ticks, ask prices, spreads, daily rollover rates - is exactly the kind of data the clients would find useful when comparing brokers as well as ensuring a given broker's marketing actually is meets up to the facts.

If it were merely a resource consideration then the option would be available but not enabled by default. Just as I can set my M1 chart to accommodate 2 billion candles or as few as 1. And the broker always has control over how much data you are going to be able to pull when you do chart refreshes...they already have the requisite infrastructure to control their cost-structure in terms of bandwidth and server usage. I can refresh a daily chart and get daily data going back to 1978 but the M1 data might only go back 2 weeks.

There is no resource-driven reason why they can't extend the existing model to incorporate retained tick data that is fed at an even shorter timeframe...however unlike the OHLC price data for every candle, not every customer gets the same price data via the ticks...and that is an inconvenient truth to have sitting around in people's log files.

For example consider the problematic scenarios wherein customers are calling in asking why their EA did not get that one tick with price xyz last friday which was at the price that my trade would have closed at? and instead my computer missed that tick and my trade subsequently closed for loss when stoploss was triggered by market gap over the weekend! Right now with no official log data there is no proof, nor will there be proof in MT5. If I am a broker this works for me. All the customer has for proof when it comes to price history is OHLC of M1 data at best.

Tell me, did you guys ever get a satisfactory reason as to why your ability to easily backtest with your own tick-files was intentionally circumvented? Was that done out of resource concerns? How thoughtful of them...

Reason: