Errors, bugs, questions - page 213

 
Olegts:

As you can see from the figure, only three cores are working, I have seen more than one situation where during testing the number of cores involved in work gradually drops to zero, after which all cores start working at once, i.e. there is downtime, why the freed cores do not start working at once?

In order to start calculating the next generation, we should first process the current generation. All runs of the current generation must be completed in order to select the best ones and perform genetic operations between the best ones. Only then can the next generation be started.

When there are a few missing results left to complete processing the current generation, the freed test agents are out of work.

 
stringo:


Thank you
 
Virty:

What is the maximum time that can be set in EventSetTimer( )?

INT_MAX? I think not. I don't want to investigate it myself and it's not in the help.


Any time can be set here, but in the tester the time will be taken modulo 50 days. Approx. 4 220 000 seconds.

The quality of MQL5 demotivates me.

 
Virty:

Any time can be used here, but in the tester the time will be taken modulo 50 days. Approximately 4 220 000 seconds.

The quality of MQL5 is demotivating.

You can set a maximum of 2 147 483 seconds (corresponding to 35 791 minutes, 596 hours or 24 days). This is not how the timer is handled in the tester.

Counter question. Why set the timer to 24 days?

 
stringo:

A maximum of 2,147,483 seconds can be set (corresponding to 35,791 minutes, 596 hours or 24 days). This is not how the timer is handled in the tester.

Counter question. Why set the timer for 24 days?

I want the position to be closed after opening in time from 1 second to 10 years, depending on something.

I tried it this way

request.type_time=ORDER_TIME_SPECIFIED; // The order will be valid until the expiry date
request.expiration=1; //or TimeCurrent()+time; (int time=1;)

Doesn't work with seconds.

Bypassed this problem with EventSetTimer( ). Also limited to 24 days. Most importantly, I didn't expect such a mess from the timer. You should have been warned. Oh well.

By the way, is the time in the timer the real calendar time or just the trading time? In other words, immediately after the weekend how much time is shown on the timer?

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 

Again a case of partial loss of communication between the terminal and the server has been reported. Build 360. No quotes are received, but information on time and volume of transactions is updated. There is a rotating circle with grey sectors on the connection status indicator. There are messages in the log:

2010.11.29 18:03:03 Trades '630031' : deal #2107036 buy 0.10 GBPUSD at 1.55387 done (based on order #2157432)
2010.11.29 18:00:02 Trades '630031' : deal #2106895 buy 0.10 GBPUSD at 1.55341 done (based on order #2157265)
2010.11.29 17:07:49 Network '630031': authorized on MetaQuotes-Demo
2010.11.29 17:07:47 Network '630031': connection to MetaQuotes-Demo lost
2010.11.29 16:10:47 Network '630031': trading has been disabled - investor mode
2010.11.29 16:10:47 Network '630031': terminal synchronized with MetaQuotes Software Corp.
2010.11.29 16:10:47 Network '630031': authorized on MetaQuotes-Demo
2010.11.29 16:10:45 Network '630031': connection to MetaQuotes-Demo lost

Note no "terminal synchronized with MetaQuotes Software Corp." message after 17:07:49, at the same time new trades are reported.

 

Rosh:
Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.


Here you go.

Test system (whatever it was!): Windows XP SP3, Pentium 4, 3GHz, 1.25Gb memory

All the runs were performed using Alpari-Demo, GPBUSD M1, period 04.10.2010-05.11.2010 (1521376 ticks, 34194 bars) in Normal mode, every tick, deposit 10000USD (by the way, where did you get 1000000USD deposit? My list ends with 100000), leverage 1:100. I have constructed an Expert Advisor that uses the peculiarity of the Alpari-Demo account - zero margin - to simplify its construction. For every tick, the Expert Advisor opens an order of 0.1 lot in one direction, until it reaches the amount of trades specified using the parameter, the rest of the ticks are skipped. Thus, the influence of the number of trades is minimized (1 trade was obtained on all test runs). By the way, at the end of each test we checked the approximate time of forming the report in the format Open XML (hasn't exceeded the threshold of patience so far). Trades generated by the tester at the end of testing were not taken into account (one trade per run).

Thus:

The first series of tests from 10 to 100 trades with 10 increments are not of interest due to small test time - tick generation time from 5359 to 6453.

The next series is from 100 to 1000 trades in 100 increments (the result for 100 is taken from the previous series):

Transactions Time, ms Total time, ms
Approximate time of xlsx report forming, sec. Notes
100 6359 6813
5 Less than 5 seconds
200 6172 6594
5
300 6875 7375
7
400 5734 6094
10
500 6109 6562

14

600 6281 6687
17
700 8016 8563
23
800 7281 7719
28
900 9047 9610
35
1000 8453 8812
44

All in all good, but the report generation problem is starting to show up

 
Ashes:

All runs were performed with Alpari-Demo, GPBUSD M1, the period 04.10.2010-05.11.2010 (1521376 ticks, 34194 bars) in Normal mode, every tick, deposit 10000USD (by the way, where did you get the deposit of 10000USD?
It is not a problem, the required amount can be entered manually.
 

The final series (further testing on this hardware is too harsh for me;) from 1000 to 10000 in steps of 1000:

This is where the brakes that Rosh has questioningly referred to show up in all their glory.

The trades Time, ms Total time, ms
Approximate time of xlsx report generation, sec. Notes
1000 8453 8812
44

2000 26750 27266
159

3000 60782 61141
355
**
4000 125469 171391
480 More than 480 seconds **
5000 414609 459281
No data No report generation for runs greater than 4000 transactions
6000 600610 601094
No data

7000 648234 675576
648234 675576 No data

**
8000 1082437 1082796
1082437 1082796 No data

9000 1465203 1508359
No data

10000 1988031 2012500
No data

To paraphrase Rosh, as you can see from the diagram, the dependence of testing time on the number of RATEs is NOT strictly linear. Rather, it is not linear at all.

The result at 5000 and 6000 is probably a little bit overestimated, but a trend can be seen.

I want to remind you that this result was obtained using the simplest Expert Advisor that practically does not spend time on any analysis and does not use indicators; i.e., results would be even worse in a working EA.

For comparison:

Running this test with 10000 trades on a Windows 7 machine, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) took 472866ms.

In the light of the above, there is some probability that some of the candidates for the Championship 2010 could have been unjustly eliminated because of the 15-minute barrier and peculiarities of the tester (if there were a lot of deals).

** - several times at the end of the tester, the chart of the symbol showing trades was not displayed.

 

Interesting:
Это не проблема, нужная сумма может быть вбита руками.

Thank you, I didn't know.