MetaTrader 5 Strategy Tester and MQL5 Cloud Network - page 4

 
Renat:
You are confused. It will be a huge network working with any broker. You can run tests with any broker's data transparently. Press Start and you're done: all market environment data (symbols, configs, charts) will be downloaded, checked for synchronisation automatically. No need to register brokers in the network, data from different brokers will never overlap, the whole server part of the network is a huge data cache and in most cases you will not even have to re-download the history.

So that's what I'm saying: one broker has a history of Eura since 1999, the second since 2005, the third since 2010. The only thing to do is to hope that you will have more instruments and the history will be more or less correct.

But if the brokers get their act together and make the right history (I doubt it more and more) everything will be great.

Trolls:
it turns out it won't be one huge network where all the MT5 users are united. But it will be split into pieces by DC. If we take into account that de facto normal history is available only in one place and for a limited number of instruments, it becomes a bit sad...

There is an alternative. The Expert Advisor can be tested on quotes from MQ and then with the help of a sledgehammer, an autogene and other Russian tools to fit the Expert Advisor to a particular broker.
 
-Alexey-:

Dear Renat,

Will there be supercomputers on this network (would be very useful)? I would like to have advanced capabilities on par with global competitors. And one more request - please make, if possible, so that the network computing resource can be used (if desired) for the real-time calculation of indicators and Expert Advisors, not only for testing. Otherwise, everything loses its meaning - why have super power for testing, when the indicator or Expert Advisor simply has no time to be calculated at runtime (bottle neck).


Theoretically, the remote agents and certainly local ones can be combined into a pool (if you provide such a possibility in the terminal and the tester, of course).

But what's the point of doing all that if MQL itself runs in "one thread" and only one core is recognized during single tests.

Suppose the developers develop something similar and the system will learn to "distribute" a single test to different cores or throw them into a pool...

Dream on, waiting for MT6 :)

 
Interesting:

That's what I'm talking about: one broker has a history with Euras since 1999, another since 2005 and a third since 2010.

What does the depth of broker's history have to do with it?

The optimization through MQL5 Cloud Network is the same as the optimization on your computer (only faster).

If the terminal is connected to Alpari, the optimization will run on Alpari data, even if it is physically performed on hundreds of other computers in the network. The data is synchronized and all the tests are performed under the same conditions.


And the question of the number of instruments and the depth/quality of history of different brokers is not in this thread.

 
komposter:

What does the depth of broker's history have to do with it?

Optimizing through the MQL5 Cloud Network is the same as optimizing on your computer (only faster).

If the terminal is connected to Alpari, the optimization will run on Alpari data, even if it is physically performed on hundreds of other computers in the network. The data is synchronised and all the tests come out in the same conditions.


And the question of the number of instruments and the depth/quality of history of different brokers is not in this thread.

That's how I'm talking about what the story is now at Alpari we all know very well.

i am well aware that it is not in this thread, but my post dated 2011.02.23 09:46 is correct (especially the final part).

 
komposter:

What does the depth of broker's history have to do with it?

Optimizing through the MQL5 Cloud Network is the same as optimizing on your computer (only faster).

If the terminal is connected to Alpari, the optimization will run on Alpari data, even if it is physically performed on hundreds of other computers in the network. The data is synchronised and all tests are performed under the same conditions.


And the question about the number of instruments and depth/quality of history of different brokers is not in this thread.

Andrew then it turns out that the one who will participate in the network, will download the history (necessary for the tester) before testing. now multiply this history by the number of brokerage companies + add that there are many instruments. add here the exchange (because it will appear one day) make a correction for the fact that everyone has a different history !!! .... Calculate the traffic please ... and the amount of disk space needed ...

P.S. "And the question about the number of instruments and the depth/quality of history of different brokers is not in this thread."

- what if not in this one ? or you do not care what story you're testing ? you have one story on your computer, i have another ... and the test results are combined ... if i'm not sure what data was (is) tested, then it does not need this fucking test (and pay money for it ...). because the confidence in the results is zero ...

 
Trolls:

Just checking if there is a story, if not, another agent, that's the solution :)
 
Trolls:

Andrey then it turns out that the one who will participate in the network, will download the history (necessary for the tester) before testing. Now multiply this history by the number of brokerage companies + add that there are many instruments. add here the exchange (because it will appear at some point) correct for the fact that everyone has a different history !!! .... Calculate the traffic please ... and the amount of required disk space ...

I think most of the optimizations will fit into 3-4 standard pairs and a few popular brokers.

And I liked mrProF's option - it probably will.


Trolls:

Z.I. "And the question about the number of instruments and the depth/quality of history of different brokers is not in this thread."

- but what if not in this topic? or you do not care what story you're testing on? you have one story on your computer, i have another ... and the test results are combined ... if i'm not sure on what data testing took place (happening), then it does not need this fucking testing (and pay money for it ...). because the confidence in the results is zero ...

The story will be SYNCHRONIZED. And the tests will only be done if the story is IDENTICAL.

 
komposter:

I think most of the optimisations will fit into 3-4 standard pairs and a few popular brokers.

And I liked mrProF's option - it probably will.

The history will be synchronized. And the tests will be performed only if the history is IDENTICAL.

No, as now it will be synchronized on the first pass.

Otherwise a situation may arise that no one agent in the network will have history for a particular symbol at a particular broker.

But there is one peculiarity here, if the history and test parameters will be cached somewhere inside the server part (in dispatchers) it can save a lot of time.

 

MQL5 Cloud Network settings for MetaTrader 5 Agent:

For an agent to work in the MQL5 Cloud Network, just enable "Allow public use of agents" checkbox. The agent will connect to a geographically close (for example, every 5 minutes) network manager to check the availability of tasks at a certain interval (estimated by ping + busyness). If tasks are available, the agent accepts and processes them and starts actively requesting new ones without delay. As soon as the tasks run out, the agent goes back into infrequent polling mode, which reduces traffic and workload.

For the agent to start bringing in money, you should enable the "Sell computer resources" option and be sure to specify your active login from the MQL5.community. Resources will be provided free of charge if this option is not ticked or correct login is not specified. Even if agents were initially registered without linking to an account, you can change this at any time - just add a new login and the agent will be automatically re-registered to a new account the next time you make a connection.

You can even re-register an agent from one working account to another. In this case the amounts previously earned will remain on the old account, while new tasks will be paid on the new account.

An important feature of working in MQL5 Cloud Network mode is that agents connect to dispatchers [1-9].mql5.com via SSL(443) port, which allows them to pass firewalls and proxy servers.

The new agent will operate in hybrid mode:

  • Normal server mode, opening the server port, requiring authorisation and waiting for connections from client terminals (as agents work now). In this mode, the agent is always available to work.
  • The client mode of working in MQL5 Cloud Network that independently accesses external task managers at an allowed time, which is specified in Scheduler



    . You can create a schedule for a week by the hours when the agent is available to work in MQL5 Cloud Network. For example, you can set 24 hours on weekends and 9 hours (from 22:00 to 07:00) on weekdays.

    This schedule does not apply to normal server mode of agents - in this mode, agents are always available.

We will also do some serious tuning of how agents use resources:

  • In rest mode, they will spend an extremely low amount of resources (memory, threads and priority)
  • agents will use flexible management of threads priority, memory and CPU usage when they are active
One of the main goals is to allow agents to work without interfering with users who are working.
 
I don't have that tab... What do I need to do?
build 404, ran metatester64.exe - only the first two tabs are there
Reason: