
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
Identify a break in communication
I don't know how to do this.
I don't know how to do it.
What makes you think they happen and OnTrade gets lost? From the documentation?
What makes you think they happen and OnTrade gets lost? From the documentation?
Because Relogin resets the historical cache, which (I assume) is doped through the OnTrade mechanism.
Not sure how to do this.
Without getting out of MT5 intertiki time, if possible. And with trading operations in relation to the order in the DC without in-house help, I can't think of anything.
Not getting out of MT5 intertitle time, if possible. And with trading operations in relation to the order in the DC without in-house help, I can't think of anything.
I don't get it.
I don't get it.
Yes, something is wrong. The inter-tick time is only for missing ticks due to a break in communication. And in terms of queries and correctness of responses on orders, trades and position states, if the response is missed or changed due to communication failure and lags because of this, there seems to be no cheap solutions. Re-querying on the next tick is not always an option.
The solution for me would be an internal function to track the status of trades/positions with respect to orders to open, modify, partially close, and fully close a position. The request for tracking the result could be set in the order itself. And get the result on the current tick and not on the next one.
Can you tell me what to do so that I don't have to deal with this while trading?
Judging by the time of logging, everything happened in 7ms.
If you want to have a constructive discussion, give us the complete test conditions (server, account type, number of selected symbols, number of EAs, etc.).
The SymbolInfoTick runtime measurement code:
On MetaQuotes-Demo server (20 symbols selected, Netting, 4 open positions):
131 symbols selected, 10 open positions:
Judging by the time of the log entries, it all happened in 7ms.
That's three different EAs.
If you want constructive discussion, then give all test conditions in full (server, account type, number of selected symbols, number of EAs, etc.).
Real account, RannForex-Server, 16 symbols, M1 chart open on each (5000 max bars), on each one an EA is running, which accesses only its own symbol.
There can be about 50 positions and the same number of orders at a time. There are no indicators, and only CopyTicksRange (fresh ticks) and SymbolInfoTick are used to get the prices. There is no reference to bars.
These are three different EAs given out.
Real account, RannForex-Server, 16 symbols, M1 chart open on each (5000 max bars), on each one an EA is running which only refers to its symbol.
There may be about 50 positions and the same number of orders at a time.
If I understand correctly, there's not an EA there, but a stress tester on each symbol. This changes things completely. And it shows the hiding of initial conditions.
That is, 16 threads on an 8(4+HT) processor (+N worker terminal threads in parallel) non-stop and without delays break into one synchronized symbol database object. Read/Write locks are mixed up because there is constant tick writing.
Usually in such a profile, depending on steepness of the processor and its mastering of threads, each thread can spend from 60% to 80% of time waiting.
And this is regardless of task type.
If I understood correctly, there is not an EA there, but a stress tester on each symbol.
Wrongly understood. Each EA is purely trading (in the Tester by real ticks does not slow down) and does not depend on others. All trading logic is executed only in OnTick, no spamming of trading orders, no recursion, no globalization and no resources.
OnTrade*, OnBook are not used. Second timer and OnChartEvent for the case when certain keys are pressed.
I am sure that proper implementation (by you or me) of snapshots will greatly reduce the number of calls of regular environment functions. Correspondingly, lags will be drastically reduced.
I never thought it would come to snapshot tricks. I'm studying the question, as standard MT5-advisor implementation is lame, unfortunately.