Multi-EA Orchestration - How to do it? - page 3
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
I assume that your code would also be limiting the number of trades with something like PositionsTotal() or deal status. If EA1 opened a trade, the trade count would equal 1 and the master GV would equal say, 2.0, representing "in-the-market." As EA2 would be conditional on the trade count being zero and EA1 being "out-of-the-market," EA2 wouldn't trade... and so on regarding EA3.
When I need values "set in stone" and accessible to multiple indicators and/or multiple EA's, I frequently use GV's. In this way, I've never experienced race conditions. The GV values simply update in sequence.
My pc has a 2019 Intel Core i7 processor. Nothing special. I have no idea what you're running, of course.
thanks
some more details: i intend to run this multi-EA system on 10+ pairs concurrently. each pair will need at least 3 x charts of different timeframes each chart getting its indicators...lowest TF is a custom seconds chart.
i am glad to hear that GV served you well and didn't lead to race conditions....how many EAs were you roughly running? chart and indicator count?
for me, It is a very probable scenario that two or more related pairs ( say ...EURUSD, GBPUSD) might raise a trading request at the same exact time for the same candle.....that is the issue i am trying to address ....which is not addressed by a simple locking ( aka mutex) mechanism...because there needs to be an element of arbitration/prioritization (which EA should be allowed to go).
thanks
some more details: i intend to run this multi-EA system on 10+ pairs concurrently. each pair will need at least 3 x charts of different timeframes each chart getting its indicators...lowest TF is a custom seconds chart.
i am glad to hear that GV served you well and didn't lead to race conditions....how many EAs were you roughly running? chart and indicator count?
for me, It is a very probable scenario that two or more related pairs ( say ...EURUSD, GBPUSD) might raise a trading request at the same exact time for the same candle.....that is the issue i am trying to address ....which is not addressed by a simple locking ( aka mutex) mechanism...because there needs to be an element of arbitration/prioritization (which EA should be allowed to go).
You're welcome. I've run 26 dedicated single symbol EA's, each on 26 different charts, in the past on standard timeframes without issue (because I don't believe in market-wide universality of any EA). All of those EA's called at least 3 custom indicators. I should note that I did that on an old Windows 7 machine. At the moment, I'm merely running 2 EA's: 1 to generate a custom chart, 1 to execute trades; and 9 custom indicators... albeit on a much faster machine, relative to the old one. My MT5 terminal, running this configuration, uses only between 0% and 1% of CPU resources. I should also note that I'm a bit better now at embedding indicator code into custom functions in an EA, as long I don't want to go plot-happy... so I tend less to go chart-happy now.
The only potential snafu that I foresee in your configuration is related to custom chart generation. Presumably, you have 10 custom chart generator EA's, each running on a standard timeframe. In my recent experience, custom charts tend to lag versus the Market Watch even if only for milliseconds because the generating code takes time to run. I could care less about this because I'm a futures swing trader. You, on the other hand, are analyzing data down to the second (x 10 charts). I have to guess that you don't want delays of seconds nor milliseconds. Of course, your generator code could be more efficient than mine and not cause issues.
I don't know anything about mutex but I wouldn't need it to do what you're doing. A sequence of if-then statements or switches, coupled with GV's and open position counts, in your respective trade execution EA's, can do the trick. Some simple "EA1ran", "EA2ran", and "EA3ran" GV's that update as each respective EA evaluates trading conditions might help you further prioritize. If you don't want to check deal status, Sleep() or a tick/time counter delay can prevent duplicate trades due to a slow trade-server connection (but they won't work in the MT5 Tester).
If you want to do a hodgepodge load test on MT5 before coding your strategy; I would just generate a bunch of custom charts, open some more standard charts, stack on a bunch of indicators... and see how MT5 and your machine handle it.
chuckdavis #: some more details: i intend to run this multi-EA system on 10+ pairs concurrently. each pair will need at least 3 x charts of different timeframes each chart getting its indicators...lowest TF is a custom seconds chart. i am glad to hear that GV served you well and didn't lead to race conditions....how many EAs were you roughly running? chart and indicator count?
for me, It is a very probable scenario that two or more related pairs ( say ...EURUSD, GBPUSD) might raise a trading request at the same exact time for the same candle.....that is the issue i am trying to address ....which is not addressed by a simple locking ( aka mutex) mechanism...because there needs to be an element of arbitration/prioritization (which EA should be allowed to go).
You do realise that EA's don't need to have multiple charts open. It can easily instantiate multiple indicator handles, each on a different time-frame and symbol, without the need to have those charts open at all. Even a Service, that is not attached to any chart, can do this.
Also, if those indicators are of your own design, or you have their code, you could even modify them to be able calculate the results on multiple time-frames at the same time, all while only depending on one single lower time-frame.
You can easily reduce the work-load of your entire system, so much and to the point that it can easily do everything from a single EA, without the need for anything else.
In other words, your current system is just too "bloated" and over complicated—hence my initial words about an X/Y problem. Your real issue "Y" is the lack of efficiency and clarity, not "X" the lack of an IPC .
lso, if those indicators are of y
You do realise that EA's don't need to have multiple charts open. It can easily instantiate multiple indicator handles, each on a different time-frame and symbol, without the need to have those charts open at all. Even a Service, that is not attached to any chart, can do this. --> yeah i know...in fact that's what i do...cpu still needs to process those indicators/Tfs....no gfx saves some processing overhead.
Also, if those indicators are of your own design, or you have their code, you could even modify them to be able calculate the results on multiple time-frames at the same time, all while only depending on one single lower time-frame. --> i need to create indicators and further process the outputs. i would rather use several handles each running on different TF than cramp it all into a single TF. besides i profiled "copybuffer" and found it to be a crappy function with high cpu overhead....don't use it at all!.
You can easily reduce the work-load of your entire system, so much and to the point that it can easily do everything from a single EA, without the need for anything else. --> not so sure on this one...even though i do all my indicator processing on candle close...it is quite a bit of processing to jam into a single thread : ~20 pairs x 3 TFs/handles x 5 indicators... even for my highly efficient code there is need for looping over candles and no way to avoid it. no nested loops though. also i have built a simple multi-sym EA using the spy technique published by Kostantin Gruzdev "https://www.mql5.com/en/articles/234" . a good idea, though i can't use it on a seconds chart simple becuase there is no predefined "PERIOD_10S" for example...i.e you are limited to the built-in TFs....so lowest i can go using this is 1min.
In other words, your current system is just too "bloated" and over complicated—hence my initial words about an X/Y problem. Your real issue "Y" is the lack of efficiency and clarity, not "X" the lack of an IPC .
No, not by calling other Indicators via handles, but by calculating internally and incrementally to reduce CPU and RAM load.
For example, instead of individually calculating multiple moving averages applied to various time-frames, it is faster and less intensive to carry out a simpler combined calculation using incremental changes to derive the values of all the moving averages simultaneously, using much less CPU and RAM.
You are not thinking outside the box! What about all that wasted time doing nothing between the "new bar" events?
Also, if there are 3 time-frames, then obviously the "new bar" event for each one is not necessarily all at the same time. Spread out your workload.
You don't have to do that with generation and/or indicators. You can do that in other ways, but I can't give you much advice as I have no idea what your strategy is or what requirements you have.
Anyway, I wish your best of luck and good coding!
i have built a simple multi-sym EA using the spy technique published by Kostantin Gruzdev "https://www.mql5.com/en/articles/234" . a good idea, though i can't use it on a seconds chart simple becuase there is no predefined "PERIOD_10S
You might look into creating a new flag and corresponding flag event for your custom S10 symbol. Gruzdev's code uses time.min in a time structure for the event, so time.sec should work. As that code appears to call symbols from the Market Watch window, your custom chart symbol should be in there. Of course, all trade execution code would still have to specify a tradeable symbol. (This kind of bifurcated code is how I auto-trade custom Renko charts.)
From Gruzdev: "We are not limited to strictly defined time intervals, as when using the OnTimer()."
Full disclosure... I've been working on embedding "abstract" Renko bar code into an EA consistent with Fernando's above advice.
thanks all for your valuable input.
@ryan/@fernando ... special thanks and heads up ! I might reach out via msg for follow ups :)