Indicators: Ping - page 2
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
It's actually not small ~ 5 ms. A stone in the garden of those who suffer from zero ping.
On build 1703 the average lag is the same. But surges became much less.
Conducted an experiment. Started a torrent on a machine with MT5, this is the situation
This means that if someone is actively using the network, the terminal lag can be up to 2 seconds. This is especially important to understand for those who use VPS, where the network channel depends not on one, but on many clients. And putting a news TS on such VPS, for example, becomes very risky.
And, in fact, it was initially stated that indicators in Expert Advisors are a bottleneck, since all indicators are executed in one thread, unlike Expert Advisors. Lags in Expert Advisors require a separate study. The function of getting lags is in the description, so it is not difficult.
Could you tell me where it was stated that the indicators called in the Expert Advisor are executed in one thread, and the Expert Advisor parallels the tasks itself in some way?
It seemed to me that just the opposite - the indicator is a separate programme and can calculate easily in a parallel thread, but the calculation will have to wait if it is not completed for some reason. I know that in the strategy tester everything is in one thread.
Could you tell me where it was stated that the indicators called in the Expert Advisor are executed in one thread, and the Expert Advisor somehow parallels the tasks itself?
Forum on trading, automated trading systems and testing trading strategies
Can someone explain the meaning of application in Expert Advisors :....
Renat Fatkhullin, 2010.02.06 13:06
An indicator is a calculated entity, which has strict requirements to work out. It has no right to slow down and not produce data (and data is required from it unconditionally).
Indicators work in their own flow, processing each price tick and any delay will lead to blocking of the whole system (the consequences will be very diverse).
We had fears that working with objects would lead to serious brakes of indicators (working with objects goes through a special asynchronous queue of messages). Experiments have shown that if objects are used reasonably (without moving hundreds and thousands of objects at a time), they do not significantly affect the calculations. That's why we allowed the use of object management functions in custom indicators. But if you want, you can easily create brakes in the terminal by unintelligent work with objects in the indicator.
To understand what an indicator is, we need to look deeper - into access to historical data. When an indicator is called via OnCalculate, it is given the available history.
If you look at its volume (by displaying counters in logs), you will see that tens and hundreds of megabytes are actually given on each tick:
From the global history manager, which updates on a tick-by-tick basis, caches and recreates timeframes on demand.
They are blocked for reading and provided by the terminal to each indicator in turn.
Theoretically unlimited number of indicators, but one by one.
Memory is catastrophically lacking, so there is the only way for indicators to work one by one.
The peculiarity of MetaTrader 5 compared to MetaTrader 4 is that now the volume of history has increased many times and we have solved a very difficult problem of fast (without copying dozens of megabytes of history for each indicator separately) recalculation of indicators. Even two (or more) identical indicators on identical timeframes are merged into one calculation copy and counted once.
Now you propose to take and slow down the whole mechanism, actually making pure experts out of indicators. It is absolutely clear that this is technically unreasonable. Adding interactivity to indicators will immediately destroy the working mechanism of working with the terminal core - access to data.
As a result, we will get a "slow terminal, they can't even draw an indicator, and charts are drawn with a delay!", and no one will say "yes, it's my fancy indicator that works, it's his fault". And even in this case we will be accused of "not providing reasonable separation, not knowing how to write multithreaded software, etc.".
Therefore, there will be no fundamental change in the behaviour and principles of indicators' work.
Thank you for the information you have found.
The year 2010 immediately catches my eye, as we know "never say never", so it would be interesting to know what is going on now, whether there are really no changes.
Besides, it follows from Renat's answer that each indicator works in its own thread, so does it not follow from this that at least two threads can exist simultaneously for an Expert Advisor and an indicator?
Renat claims that the delay is caused by the need to provide the indicators with a large amount of data(in fact, tens and hundreds of megabytesare given on each tick), but according to today's realities, this is not such a large amount of data, and it is quite possible that for the work of the same indicators with the same instruments, a joint stream of historical data will be organised, but a different stream for calculating the indicators themselves, which was partially already organised in 2010"We even have two (or more) identical indicators on the same timeframes merge into a single stream.
Even if this is true, it is quite possible to merge indicators into one cluster and apply OpenCL there (I have never applied it myself because of little information for dummies on organisation).
I'd be interested to know what's going on now
One, two, three, four.
One, two, three, four.
Thanks, I took a good look at the search results. It's mostly the same old stuff.
In the end, we have one thread per symbol for all indicators on that symbol. And we have a thread for each (?) EA. So, if we use information for decision making from different charts, the use of indicators is preferable?
Indicators have an advantage - convenient work with the history of calculations.
Perhaps, if you make calculations on each tick, the indicator can become a bottleneck, because it will try to give the most relevant data, but if the calculation is based on OHLC, then parallel calculation should give an advantage. As long as the Expert Advisor requests information from indicators, after checking the situation with the current position, this data will already be ready for reception. And yes, I make calculations in indicators only at the opening of a new bar. And if the logic of indicators is combined, it will be even faster, or do you have a different opinion?
Aleksey Vyazmikin:
or do you have a different opinion?
change the thread.
Hello, is the unit of measure of ping in seconds?
It's described. Didn't you read it?
"The delay of the quotes is calculated in milliseconds;"
I remembered this great indicator.
This is a picture from a machine with zero ping. It turns out that the internal lag of the Terminal is ~2 ms on average. It jumps in the range of 0-9 ms.
For example, two ticks came to the server: first one, in 10 ms - the second one. So in the Terminal you can get the second tick not in 10 ms after the first one, but in 10-19 ms. On average in 12 ms.