Question about Money management on MetaTrader platform
ukt
You can never get a perfect solution for that.
You can try making a "semaphore" : something like "now I am about to place an order the others must wait" (it will not work with global variables since global variables are created in the folder where terminal is), but in the case of semaphores you can miss signals as well what happens when you get re-quotes, errors, trading not allowed and ll the rest in the arsenal of preventing order entry in the times of fast price changes
Summary/background of question is this:
I believe, due to the single threaded nature of MT4 regards trading operations, that there are those that get around this issue by running one ClientTerminal for each chart symbol/timeframe and apply the expert to it.
In this way each expert runs solo and will not be constrained by the one trading thread issue due to other competing experts also wanting to trade ASAP.
This however raises money management issues/questions which I hope are set out clearly below.
Thanks for reading!
I need some understanding on how some of you who run many ClientTerminals - all same expert and some/all using same account# deal with eg, daily draw down limit, maximum money risk, ...
On single Client, one way to deal with each expert's 'slice of the money cake' if 2 or more on same ClientTerminal/account# could be:
dMyMoneySlice = dEquity*dRiskPcent/dCountOfTradingExperts; //GlobalVariable
This basic idea (or variant of), I am happy with...
?what about when we introduce say 2 ClientTerminals running same/one expert on same account#.
As I understand it, we have 2 experts which do not 'know' about each other. RiskPcent must be divided by 2 (in this example).
So how achieve in an n ClientTerminal environment? and additionally, experts could stop/restart at any time etc. NOTE:This is not an issue in the one ClientTerminal example, as each instance would obviously be updating their local copy of 'count' or whatever mechanism is chosen - as long as they are dynamically aware of the changed 'count'..
external var is static and unable to react to changing number of experts running so would appear to not offer solution.. and file sum store seems slow and potentially? R/W contentions and delays, may emerge..ukt
You can never get a perfect solution for that.
Well... is kinda what expected to hear but hey - never know!
You can try making a "semaphore" : something like "now I am about to place an order the others must wait" (it will not work with global variables since global variables are created in the folder where terminal is),
Yes, understand. Actually, at present I have a semaphore used by all instances running on single terminal. It's pitched at one level above MT's IsTradeAllowed() and IsTradeContextBusy(),such that via atomic access with GlobalVariableSetOnCondition() only one instance can proceed to engage in calling dLots() and dealing with 'account information' functions - my thinking being that the sem acquirer has sole use of all information for calcs and of course for making a trade or indeed OrderModify().
but in the case of semaphores you can miss signals as well what happens when you get re-quotes, errors, trading not allowed and ll the rest in the arsenal of preventing order entry in the times of fast price changes
Ouch.. the missing of signals is painful for sure and although my start(),trade[prospecting,Management] areas are tick based, am attempting to ensure a certain width signal window such that a lookback idea used (if needed). Requotes, errors are indeed a stumbling block. To deal with fast moving prices, my strategy uses OP_STOP which helps in this area.To be honest, not sure what brill idea I expected. Your answer is actually spot on - in that no perfect solution. The great thing about you/forum is that one gets a reply - I'm indebted to you for that 
Maybe... say 5 or so instances on one terminal is no big deal. It really kept bugging me do to all the issues a single terminal brings to the game. Then I totally lost the plot when 'expertsCount' came to play. I had the idea ok for one terminal, x% risk divided by count. Finally hit me hard when realised that 'what ya gonna do with separate terminals?'
I have posted elsewhere, but no joy - my type questions generally go unanswered.
Cheers!
:)
I guess that people actually did not think what can happen when 2 or more terminals from a same account are working at the same time and that is why you got no answer.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Summary/background of question is this:
I believe, due to the single threaded nature of MT4 regards trading operations, that there are those that get around this issue by running one ClientTerminal for each chart symbol/timeframe and apply the expert to it.
In this way each expert runs solo and will not be constrained by the one trading thread issue due to other competing experts also wanting to trade ASAP.
This however raises money management issues/questions which I hope are set out clearly below.
Thanks for reading!
I need some understanding on how some of you who run many ClientTerminals - all same expert and some/all using same account# deal with eg, daily draw down limit, maximum money risk, ...
On single Client, one way to deal with each expert's 'slice of the money cake' if 2 or more on same ClientTerminal/account# could be:
dMyMoneySlice = dEquity*dRiskPcent/dCountOfTradingExperts; //GlobalVariable
This basic idea (or variant of), I am happy with...
?what about when we introduce say 2 ClientTerminals running same/one expert on same account#.
As I understand it, we have 2 experts which do not 'know' about each other. RiskPcent must be divided by 2 (in this example).
So how achieve in an n ClientTerminal environment? and additionally, experts could stop/restart at any time etc. NOTE:This is not an issue in the one ClientTerminal example, as each instance would obviously be updating their local copy of 'count' or whatever mechanism is chosen - as long as they are dynamically aware of the changed 'count'..
external var is static and unable to react to changing number of experts running so would appear to not offer solution.. and file sum store seems slow and potentially? R/W contentions and delays, may emerge..