Is tick history available on the server?

 
Is there a tick history on the broker's server? Or does the broker need to plug in homemade scripts for this ?
 
Currently, tick history is not stored anywhere, only timeframe history.
 
Currently tick history is not stored anywhere, only timeframe history. <br / translate="no">


Is it such a huge problem for a tick history to be stored and for minutes to be selected with data from ticks or volumes?they will be counting by ticks. those who tick is not checked, they will store the archive by default as it was before today, and they will have to add ticks in the tester, use ticks, that's the deal!

What do you think? Is it a bad idea?
 
Merab, do a public calculation on tick data storage per character for 1 year, please.

Then multiply this by e.g. 50 or 100 characters. Also estimate the network traffic for maximum effect. Only figures are needed in the shortest possible way with a minimum number of words.
 
Renat,
With your permission I will do so. Still, Merab will have a hard time "in the shortest possible way with the minimum number of words".

History file string (Time,Open,Low,High,Close,Volume) = (int,double,double,double,double) = (4,8,8,8,8,8) = 44 bytes.
Tick file string (Time,Close,Volume) = (int,double,double) = (4,8,8,) = 20 bytes.
Let's assume conditionally that the average number of ticks per minute = 5. This figure depends on the broker, on filtering method and frequency of quoting. For example, the demo-server MQ for Euro has the average speed of 3.6 quotes per minute. And the brokers I deal with are even lower. Therefore 5 is a reasonable enough figure. Then we get: 5 lines of tick file per minute = 5*20 = 100 bytes.

For Forex, the Volume parameter could also be dispensed with. However, for CFD, stocks etc. we cannot do it, so we leave the Volume.

Days = 1440 minutes.
Year = 52 weeks * 5 trading days * 1440 min. = 374400 min.
M1 history file volume for the year = 374400*44 = 16 473 600 bytes = 15.71 MB
Tick file volume for the year = 374400*100 = 37 440 000 bytes = 35.70 MB
Total volume by instrument for the year: 35.70+15.71+3.142+1.047+0.524+0.262+0.065+0.011=56.461 Мб
Total volume per 100 instruments per year = 5.5646.1 Mb = 5.514 Gb

So, the tick file volume is only a little over 2 times that of M1.

The frugality of MT4 (especially in terms of traffic) is amazing, magnificent and unparalleled in the world. There is no doubt it should be maintained in the future.

However, the following must be taken into account:
1. The introduction of tick history will not cause any change in work traffic - ticks go one way or another.
2. The creation and maintenance of the history archive, which MQ is still (hopefully) working on, removes this task and traffic (!!!) from the server altogether and moves it to a separate web-server. Adding the tick history there as well would not be difficult at all, but the value of this service, which would be a component of the overall MQ offerings, would be raised even higher.
3. The introduction of such a history may ONLY lead to the need for additional disk space. And this has long been of no concern to anyone in the west. The doubling of iron capacity happens (I think) every 2 years. The smallest HDD capacity that is produced now is 80 GB (or am I lagging again ? :-) That's enough capacity for a broker for 14 years. No problem.

There is no doubt that trying to include it now in MT4 is impossible and unnecessary. No one is talking about that. However, we hope that the new MT5, which is announced to be something fundamentally new, will definitely have such features. Including a tick chart (otherwise what is the tick history for anyway?).
 
In my experience, it can take anywhere from 5 to 60 seconds for an order to open. And every time the time is different (it cannot be calculated or predicted). Why do you need a tick history if you do not really know at what tick and at what price an order will be opened? For me personally as a practitioner it is absolutely incomprehensible!
I think that this tick history cannot be used in the tester, except for "fitting the curve". So it turns out to be a deliberate self-deception. Why do you people need it?
 
Take an average user and offer them to download 5 Gb of history in a year? There's even complaining about our existing traffic, and to offer such traffic in 1 year is suicide for developers.

Think deeper about ticks and you'll realise that a tick chart won't change anything. MQL4 and the tester give powerful opportunities for experimentation. We have already understood this after our research and are trying to convey this idea to traders.

Solandr is right - ticks will only support self-delusion from fitting the yield curve. The other way should be chosen - to increase expert's sensitivity and make them thick-skinned and not affected by noise within a spread.

No one can resist the desire to go down to the most detailed level of ticks and find there the solution to their problems. Many go through this. But after this stage one has to take a sober look at the results and move up a level.
 
Take an average user and offer them to download 5 Gb of history in a year? They even complain about our existing traffic, but to offer such traffic for 1 year is suicide for developers.


Dear Renat,
I honestly implemented your proposal and you, please use these figures honestly too.

1. No average user will be "bumped" as much or as much as 1000 times less. Because the average user doesn't need it at all.

2. 5 GB is the full volume across all t/f's for 100 (!!!) instruments. Even someone who needs history doesn't need ALL instruments or ALL t/fs. Someone who works with ticks will not download H1 and above. And someone who needs H1 doesn't need ticks. When you go to a department store, you don't buy everything there. But if you don't find what you need there, you say 'bad department store'. Any service (including brokerage) is either complete or bad.

3. I've thought about ticks deeper and I'll tell you this. Neither you, nor respected solandr, nor anyone else should have to worry about "stupid" researchers. MQ gives users a very powerful tool for market research: the history + its graphic display + MQL4. As the Championship has already shown, it really can be used to detect some regularities in the market. Who does it and how and to what extent the nature of the market can be revealed is not up to you to decide. For this to be possible, it is not guidance that is needed, but freedom of creativity. If MQ wants to be consistent in its strategy, it must help to empower that freedom, not restrict it.

4. As for personal experience, dare I contrast my experience with yours and anyone else who would argue that ticks "will only support self-delusion from fitting the yield curve". Whoever wants to engage in self-deception will always find an opportunity to do so. And my desire to "get down to the most detailed level of ticks and find a solution to my problems there" has led to a very concrete solution.

5. You missed the most important thing in my post. I was writing about MT5. If tick capabilities are not provided in MT5, then by doing so MQ will have made a strategic mistake. We are all supporters and apologists for MQ here. Our wishes are a consequence, including the fact that we are rooting for you. We would like to see MQ's lead over the competition only grow over time. Keep that in mind as you read our wishes.

Sincerely,
 
I forgot to warn you - you should also multiply the figures by 10,000 users to calculate possible peak loads. One more thing: 5/6 quotes per minute is a consequence of published traded prices. If we show an indicator, it's from 20 to 50 ticks per second at least, which increases the calculated data tenfold...

That's not what I'm saying - you don't need tick quotes. But people don't understand it :) Everyone has to go through it himself.

By the way, try to prove in practice that our simulation inside M1 is much worse than the real tick movement. Start with the article "MQL4: Strategy Tester: Modes of Simulation When Testing Trading Strategies".

Thanks for the wishes!
 
Renat
That's not what I'm talking about - we don't need tick quotes. By the way, try to practically prove that our modelling inside M1 is much worse than the real tick movement.


And I'm telling you - we need tick quotes!
Having said that, I totally agree with you that they are not needed for modelling in the tester.

They are needed for 1) any in-depth market research and for 2) determining the best entry point when the signal to open a position is received. The common viewpoint of "+/- 10 pips does not matter" does not hold up. The "+/- 10 pips" value is 20 pips for SL, which is a significant value for a TP= 50-60 pips. And if we add an exit error of 20 pips, it turns out that one should not even play with such a TP. Even at TP=100 it is 40% of the target.

And that's two reasons which only I can see.

I forgot to warn you - you should also multiply the figures by 10,000 users to calculate possible peak loads.

I forgot to warn you too. :-)
You already have all these "problems" with users, tools, t/f and history. And you are dealing with them successfully. All you have to add to the current structure and infrastructure is a ticking history. It's just an addition, which IMHO will not fundamentally change neither traffic, nor anything else, since the number of those who want to search in ticks is measured not by tens of thousands, but simply by tens. :-)

Thanks for your patience.
 
They are needed for 1) любых in-depth market research and for 2) determining the best entry point when the signal to open a position is received. The conventional wisdom of "+/- 10 pips does not matter" does not hold up. The "+/- 10 pips" value is 20 pips for SL, which is a significant value for a TP= 50-60 pips. And if we add an exit error of 20 pips, it turns out that one should not even play with such a TP. Even at TP=100 it is 40% of the target.

And that's where you're caught. I specifically say - prove that the intra-minute simulation has a serious discrepancy. Especially at 10 pips. Just take the data, do the research, publish all the data obtained (including historical files) and nail us to the wall.

I argue that the margin of error within the minute modelling is within 1-2 points. And that margin of error is perfectly acceptable and normal.
Reason: