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
Turns out to be a frequent occurrence. Trading functions have not been called.
SymbolInfoTick is not a bad lag sometimes. HFT may be very experienced with such unexpected lags.
Please ask the Developers to find the reasons. In the meantime, it is obvious that in battle EAs their profiler is a must.
What will the test show on the "empty" terminal?
It should be something like this:
Unless you tell us in detail what you are doing, how exactly you are putting a load on the terminal, it will be difficult for us to find the reasons.
What will the test show on an "empty" terminal?
It should be something like this:
Unless you tell us in detail what you are doing, exactly how you are putting the load on the terminal, it will be hard for us to find the reasons.
100K iterations is not an indicator. Since the function does not always slow down, but sometimes.
In fact I need to disable chunks of the combat EA until the braking stops. Then I can provide the code. We have to wait.
In fact, I need to disable chunks of the combat advisor until the brakes stop. Then I can provide the code. I have to wait.
Run this EA on a few characters to get a quick result.
Got it in five minutes.
Looks like it's enough to leave only this (without CopyTicks) in the EA.
100K iterations is not an indicator. As the function does not always slow down, but sometimes.
I propose to change the concept of defining the fastness of a function.
A function is fast if there are no peaks in its execution time.
As was shown above, even simple functions have such peaks. Sometimes very large ones. I have no idea what this has to do with. But it is obvious that all trading-critical functions should be checked for the presence of peaks using the method suggested above. I.e. we run and monitor peaks greater than a millisecond for a couple of hours.
It is necessary to achieve that there are no peaks at least on an empty Terminal. Fast 100K iterations turn out to be nothing.
I suggest changing the concept of defining the fastness of a function.
A function is fast if there are no peaks in its duration.
As shown above, even simple functions have such peaks. Sometimes very large ones. I have no idea what this has to do with it. But it is obvious that all trading-critical functions should be checked for the presence of peaks using the method suggested above. I.e. we run and monitor peaks greater than a millisecond for a couple of hours.
It is necessary to achieve that there are no peaks at least on an empty Terminal. Fast 100K iterations turn out to be nothing.
Sometimes it happens that the timer shows a cumulative amount of time if another task is running. For example, it may happen when working with canvas - when displaying function sets the task to display without creating an image and comes back. After that any other function is executed sequentially, for example the same comment, however the process of canvas mapping is started in CPU language and only after that kanvas is displayed. When measuring the timing you can see that the comment takes a very long time to be output, but the kanvas display function runs in 0 ms.
run and monitor peaks greater than a millisecond for a couple of hours.
We need to ensure that there are no peaks at least on an empty Terminal. Fast 100K iterations turned out to be worthless.
I drafted such an Expert Advisor for monitoring.
I got the result in five minutes of monitoring.
SZZY With such value of input parameter there are much less alerts.
But the result is more significant too.
Finally, with me modifying a bunch of orders sometimes takes 3-10 seconds per order. After that it takes a long time of 0.1 seconds again.
Pulled up the server logs - it's instantaneous there.
It is very unpleasant on a battle Expert Advisor.
Some fantastic values.
Finally, with me modifying a bunch of orders sometimes takes 3-10 seconds per order. After that it takes a long time of 0.1 seconds again.
Raised server logs - there instantly.
The situation was repeated on another trading server.
The terminal modified the open position take 2.5 seconds. On the server - 2 milliseconds.
Most likely, this is also the source of problems with FORTS-execution.
Retransmits.
Forum on trading, automated trading systems and trading strategies testing
MetaTrader 5 build 1700 platform beta: Projects in MetaEditor and synthetic tools
Renat Fatkhullin, 2017.12.14 12:47
This is an indicator of the quality of communication. The percentage of retransmitted network packets in the TCP/IP protocol.
It is calculated globally at the network interface level for all applications across the entire operating system. When you suspect slowness and problems, look at this metric. Critical when the broker's server is very far away. For example for Asian traders and a broker in Europe.
Already at 3% retransmit rate you can tell you can't trade. The extreme level of retransmits is given by bad wifi.
Forum on trading, automated trading systems and trading strategies testing
New MetaTrader 5 build 2360: Expanded Integration with SQLite
Renat Fatkhullin, 2020.04.06 12:33
The norm should be less than 1%. And already 3% network loss kills low latency services.
For example, our retransmits are 0.68 - 0.75% with obviously more users (we have 17k online on MetaQuotes-Demo). And we serve the whole world, not Moscow/Russia.
Forum on trading, automated trading systems and trading strategies testing
Bugs, bugs, questions
fxsaber, 2017.12.17 22:43
Forum on trading, automated trading systems and trading strategy testing
Bugs, bugs, questions
Renat Fatkhullin, 2017.12.17 23:03
These are statistics of the network interface of the whole computer, where Metatrader is just one of the users. It is not necessarily related to the trading server.
General stats can easily be corrupted by a web browser after failing to access some glitchy and distant site. It is also possible for a local wifi to catch a network conflict and get tens of percent retransmits at random points in time.
In case of 20% retransmits there will be no connection to the trade server and the reconnects will be constant and endless. Terminal has constant connection and even 3-5% retransmits will be fatal for it to maintain long connections.
Forum on trading, automated trading systems and trading strategies testing
Bugs, bugs, questions
Renat Fatkhullin, 2017.12.18 11:36
Keep in mind that this is a technical characteristic of your local TCP/IP stack, reported by the OS, not an indicator of the quality of a particular connection to the trading servers. It includes all network activity, including system/phone activity.
The connection of a trading cluster is known to be of high quality and we log a lot of parameters (this is a standard platform functionality), collecting one-minute snapshots and subsequent analysis.
Forum on trading, automated trading systems and trading strategies testing
Bugs, bugs, questions
Renat Fatkhullin, 2017.12.18 00:13
Checked.
None of the nodes in our demo cluster, including Asia, had any restarts or retransmit level increase for the whole day (and on other days too). Everything is between 0.5% and 1.5% normal.
I seem to have a lot.
It's midnight now, quoters are rarely updated. Retransmits are increasing before my eyes. I want to put Alert on VPS to a high value > 1% for low latency trading. But with such huge values this idea becomes pointless.
What can I recommend? Do tracert to trade server? Some kind of monitoring program? In general, how to make sure that MT5 is ready for low latency?
ZS As soon as the quotes start moving faster, the index drops many times over.
Retransmitters.
I seem to have a lot of it.
5-6am:
Home (optic, ETH to router, cable to computer) - 8-19%, ping 60-70
VPS in Netherlands (momentarily 1 MT5 with 9 currencies/11 charts) - 1.2-1.6%, ping 3.7