![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Passes results do not match for optimization and single pass (service-desk - #329165 + EA in the same place)
Optimisation and single pass results do not match (service-desk - #329165 + EA there as well)
Build 619? The same problem has started to occur. But not always. Sometimes the results are even the same, i.e. I haven't performed any new optimization, but I get different results during testing for some reason. For instance, the final profit in the chart differs from the one in the list. After some time everything is restored. I have never noticed this before build 619 .
The build is still 607 (haven't updated to the new FIBO yet). Maybe the problem is multicurrency and timer (OnTick() is not used), but not sure.
Something is wrong with the latest build of the strategy tester. Suddenly (not "suddenly", but after the update to the 619 build) the Expert Advisor has practically stopped testing (the same as in application #329165) - it started consuming memory immensely (the "All ticks" mode for 5 years):
The last column is "VM size". As you can see I have 4 cores + 4 "remote" local agents (always worked fine).
At the same time the system starts lagging very badly (yup, 4GB RAM + 16GB dedicated for PageFile) and optimization speed tends to infinity. As you can see, CPU time, practically not engaged.
At the same time there are errors in the log:
This is apparently due to lack of memory.
I press "stop" - memory is not released immediately. In 5 minutes local agents disappeared, in another two minutes, memory of remote agents was freed:
Only not clear why one agent still have more than 100Mb hang (I do not believe that it took Cloud - because CPU time is not used).
Well, I disable "remote" local agents. Nothing changes (system lags and errors).
Well, I think, the error is in my Expert Advisor. Therefore I start testing a standard ExpertMACD, EURUSD, h12 from 2007.09.01 to 2012.03.26.
И... Same picture - lags, crazy memory usage (almost the same values as in the first picture) + "cannot initialize expert".
In both cases, some passes nevertheless succeed.
Log attached.
Very interesting lines:
etc. with USDNOK - in my EA one SGDJPY symbol was stitched in the code - why download USDNOK (USDJPY was successfully uploaded according to logs), instead of USDSGD?
If anything, the server is FIBOGroup-MT5 server.
P. S. I didn't see such problems in previous builds.
P. P. S. Please, check optimization of the standard ExpertMACD for the last 5 years on all ticks.
Something is wrong with the latest build of the strategy tester. Suddenly (not "suddenly", but after update to build 619) EA has practically stopped testing (the same as in application #329165) - memory starts consuming an enormous amount (the mode "All ticks" for 5 years):
The last column is "VM size". As you can see I have 4 cores + 4 "remote" local agents (always worked fine).The system starts to slow down very horribly (yup, 4GB RAM + 16GB given away for PageFile) and the optimization speed tends to infinity. As you can see, CPU time, practically not engaged.
It is not recommended to run more agents than there are cores. Excessive number of agents causes speed to drop non-linearly and resource consumption to grow. Especially when there is only 4 Gb of memory and agents eat up a gigabyte or more.
Do not install remote agents on the same computer where you work with the terminal.
There are errors in the log:
It must be due to lack of memory.
I press "stop" - memory is not freed at once. In 5 minutes local agents disappeared, in another two minutes remote memory is freed:
Yes, memory (caches) are freed after about 5 minutes. They are purposely kept for the next run, so that time is not wasted warming up most often the same data that was used on the last run.
In the latest build we've changed the way we handle caches, which has increased them for the sake of speeding up re-runs.
It's just not clear why one agent has more than 100Mb hanging around (I don't believe it was used by Cloud, because CPU time is not used).
Well, I disable "remote" local agents. Nothing changes (system lags and errors).
Well, I think, the error is in my Expert Advisor. Therefore I am testing a standard ExpertMACD, EURUSD, h12 from 2007.09.01 to 2012.03.26.
Have you recompiled the Expert Advisor after upgrading to the latest build?
In your case the problem is in slowdowns due to constant swapping and lack of memory. Advice: Disable unnecessary remote agents.
It is not recommended to run more agents than there are cores. Excessive number of agents causes speed to drop non-linearly and resource consumption to increase. Especially when there is only 4 Gb of memory and agents are eating up a gigabyte or more.
Do not install remote agents on the same computer where you do your main work with the terminal.
Did you recompile the EA after upgrading to the latest build?
In your case the problem is in slowdowns due to constant swapping and lack of memory.
A word of advice: disable unnecessary remote agents.
I disabled it, ran ExpertMACD for optimization and:
And now disabled all agents (including local agents) except one:
and now what? 4GB is not enough for one agent? (although Mem Usage is 350MB, VM Size = 1.24GB). What about those who don't even have 4GB?
Why don't you check? See previous post for replay steps.
You can look at the Cloud stats - either 4 or 8 agents - PR is still in the region of 150-190 (except one/two, which apparently fall on the browser core) Disabled remote agents... Experts recompiled. Even the regular ExpertMACD recompiled.
Disabled, ran ExpertMACD for optimisation and:
Now disabled all agents (including local agents) except one:
and now what? 4GB is not enough for one agent? (although Mem Usage is 350MB, VM Size = 1.24GB).
Why don't you check it after all? The reproduction steps are in the previous post
It was enough to look at EA's log to see the errors:
Choose correct time period and correct settings. If you use default limits, you can generate a lot of wrong settings.
It was enough to look at the EA log to see the errors:
Choose the right time period and the right settings. If you use default limits, you may generate a lot of wrong settings.
Yes, indeed, the problem turned out to be in the default parameters. I changed them - everything is testing fine. I returned to my Expert Advisor - so far it seems to be "flying normally".
So, if earlier the availability of two agents per kernel was forgiven, now it is definitely not.
Bottom line2. Was wrong, sorry for the time taken (but service-desk - #329165 has not figured it out yet)
We'll figure it out.
It's taking a long time. In the meantime, I found out what's wrong.
1) While refactoring the code, I lost explicit assignment of the variable value and sometimes (quite randomly) received random results for the opened position volume. Having fixed this error, I saw that the results didn't change - the test results didn't coincide with optimization. Various logging and tambourine tricks helped us find out that the problem is quite old:
2) Before the start of the Championship-2011, I reported that the tester makes deals on weekends. Renat promised to check it. But the problem remains to this day. Completely by accident, I chose the beginning of the testing interval 2007.09.01, which is a weekend. So, the optimizer does not perform a trade on this day but the tester does. To be more precise, it does not reach OrderSend in the optimizer on weekend, but it does in the tester. Judging by the logic of my Expert Advisor, I managed to find out that if the optimization period starts at weekend, ACCOUNT_EQUITY = 0 when the timer first goes off!!! In the tester, ACCOUNT_EQUITY = ACCOUNT_BALANCE (that is what we set in the initial deposit). If the beginning of the optimization period falls on a business day, then the behavior of optimizer and tester are identical.
So, you have two bugs:
1) The optimizer allows you to open a deal on a weekend, which should not be (and do not say that this is my error - I will correct my mistakes, while the tester's bug has been hanging for more than half a year);
2) When timer first triggers, if beginning of period falls on output, ACCOUNT_EQUITY = 0, while in tester ACCOUNT_EQUITY = ACCOUNT_BALANCE. We need to bring it to the same form (better, of course, to ACCOUNT_EQUITY = ACCOUNT_BALANCE with correction of the first error).
In service-desk on request #329165 I will attach an expert for tests.