An effective trading strategy based on multi-currency analysis of multiple DCs - page 12
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
There, there, Alexey I like your thoughts:) I'll take a maximum data definition tick 128 bytes, multiplied by 100 thousand ticks, twelve meters, from one client per day multiplied by 100 clients, gigabytes, even with my resources I can keep history for a couple of months from a hundred clients, what to say if I put the necessary hardware, for years with reliable compaction.
Even better - the server will not store anything, it will only process requests and look for the necessary data from clients who are now online or wait for those who are online and have seen this data before.
This is a kind of pia tu pia (donkey or kazy) system but for quotes. If the server finds the requested data from several clients, it distributes the downloading of different parts of the requested history from different clients, so that it does not download only one. Frequently requested parts of the history can be stored in the cache on the server.
Yes, there may be sabotage if wrong data are given. Could be solved by comparing the data from at least two different clients also programmatically. But in general, I also think that the server will be safer. You can put a laptop as a server - it does not make much noise and is relatively cheap. But then you have to dump on it and stipulate at whom it will stand :) Although it may be someone donates his computer. But then it is desirable to have at least two servers at different people and then one server with cots may disappear.
Maybe MQ will provide a server, seeing that the project is popular ;).
MQ's representatives will say - why do you need history from brokerage companies if we have our fluffy quotes in History Center, take them, use them and develop robust EAs so they will not be sensitive to quotes. This is correct, but how to check quickly that the EA is also working acceptably on data of other brokerage companies - it is desirable to have a big history with these companies for example for a year. If you do not know how to use this method we may try to check the difference between the time you see and the time you miss.
I have a dedicated, 100 megabit channel to the Internet, the traffic is only limited, outgoing bypass, for experiments enough:) Well, then, you can buy a full-fledged server, and not one and put it on the site, if the idea will work:) As the saying goes, if only for the sake of it, all the rest is not important:) Investors will be found by themselves for this venture, if the results and the sense:)) I work with ticks for a reason, as they say, you have to think globally, and everything will make sense:) For the sake of minutes I don't see the sense:) Tick is one accurate time and price, well, plus customer time, and the bar is a few values in between which may be anything, I can't even imagine how to combine and compare bars, it's nonsense, because errors will occur at every step. If you can compare ticks then bars, it's like comparing an elephant with a mouse, especially between trading centers.
What metaquote quotes server are we talking about, if it's a demo server, it also filters the quotes on trifles, I don't know about others :) Although I compared a variety of servers, something is filtered everywhere, or I don't understand that it's not filters, but it's just information that has not had time to pass, but the question is where there is no time if the difference between ticks per second and less, but even more too, filters are clearly defined by their characteristics.
I think I will write a program that robs ticks too - it won't take long. We will exchange ticks if there are problems. I think the quote server is a painful and time-consuming task. But if you do, I'll hook my client up to your server.
Piligrimm, tell me, how can you use mt to chart a close of any currency pair on a chart of another currency pair?
With the iClose function form a file with all the instruments you need, then get an averaging ratio for each instrument, for example add the last 100 bars for each instrument and divide by 100. After that, all data, for each instrument divide by its coefficient, as a result you will get values of all instruments fluctuating around one (by the way, it is convenient for further processing using neural networks, all data are normalized), after that you multiply the values of the instrument, which you want to display on another chart by the coefficient, which was obtained for the instrument on the chart which you are going to display.
OK, I understand how you take the clones of the selected pairs via iClose. Then you write these values to a file (I wonder what kind of file and what format?).
Then, I guess you somehow open this file in MT4 and it draws all the values in the form of lines connecting the Close of different instruments. At least in your screenshot, where lines connecting the cloze GBPUSD, AUDUSD and EURUSD are drawn, let alone the trend lines drawn according to some algorithm. I was just wondering, how could you draw all three pairs in the form of lines of different colours, connecting the close.
My data is loaded on the formed bar, respectively the superimposed charts should be shifted by one bar. (If anyone has downloaded within an hour after I posted the program, please correct :
ExtMapBuffer1[155-iw+ip] to ExtMapBuffer1[156-iw+ip], and other buffers similarly).
As rightly pointed out Pilgrim, the accuracy of raw data is not unimportant:) By the way, about synchronization of ticks, everything is solved in this matter, because the market reacts sequentially to events, and therefore we react to ticks as sequentially, every tick has a value, but without data of other ticks by pairs, its data are not so exactly reflected in the same graphical representation, influences - movements, overlaps, all this makes quality, without all ticks we actually blind or not so sure what exactly influence occurs. Whereas we don't get time in more precision than a second, this is compensated for by the client absorption time, the more such clients, the more precise the timing can be with nanosecond accuracy, that's all the precision in tick synchronisation :) Ten million ticks in one second will not pass, it is enough in the eight-byte time number structure, hence their order is consecutive. Tick difference in our case is the main condition, if a tick has no difference in price from the leading one, it is the first thing to pay attention to, as by definition it is not a change in price, but in simple words, error of server or client.
The close line for the tool in the window is drawn in green in MT. The others are applied after rescaling, there is an example in the attached file, I haven't managed to load it as a code in the window. The file itself is intended for some other tasks, so it has some peculiarities, besides I don't know MQL and writing it in it is very messy.
1. Brokers won't let you build a system on ticks, they have many ways to defend against it.
2. Ticks are contingent and random. They are different for everyone by definition and there is no system to it.
3. For ticks, as in quantum mechanics, there is an effect of the uncertainty principle - the measurement process affects the result. While you are an observer (on the demo), you do not affect the flow of ticks. When you start working on the real (measuring - making requests for quotes), you yourself will create a flow of ticks, which will depend on market conditions, on the mood of your broker, on the results of your work ...
Further, maybe I missed a lot, I didn't read the whole thread, but why do you need 128 bytes per tick?
IMHO, 2 is enough for the eyes. Let's use delta coding - the first byte gives increment of time (e.g., in seconds), the second one gives increment of price in pips. The price will hardly change by more than a figure during one tick, and it's unlikely that there will be more than 4 minutes between two consecutive ticks. The resulting series will consist mainly of values close to zero, and will be nicely compressed by any compression algorithm. Besides, there are not so many ticks in a day. For example, EURUSD on Alpari now has approximately 5000 ticks per day.