Libraries: MultiTester - page 30

New comment
 
Stanislav Korotky #:

I didn't see in the source changes that something was done with the clipboard.

  static bool GetSettings2( string &Str, const int Attempts = 10 )
  {
    bool Res = false;

    if (MTTESTER::LockWaiting())
    {
      Res = MTTESTER::GetSettings(Str, Attempts);

      MTTESTER::Lock(false);
    }

    return(Res);
  }

If you run optimisation, won't it take all available cores at once? I don't understand how a single test "took away" one core from optimisation (in fact, even 2 agents of optimising MT are marked as disabled).

I think I wrote it right away. Optimising Terminal has two disabled agents. Each enabled agent takes a core.

 
fxsaber #:

I think I wrote it right away. Optimising Terminal has two disabled agents. Each enabled agent takes a kernel.

It explicitly says nothing about manual disabling (or other configuration of agents) - and this nuance is still bypassed. This is the very reason I have a question about how much parallel work is automated. I naively thought from the topic and blog description that full automation was done.

LockWaiting has been seen - it is the one I formulated as locking file work. It is clear that lock can be used to access resources, including the clipboard. Terminological confusion.

PS. Maybe I misunderstand something, but if only exclusive access to the clipboard was required, then the same lock (a loop with periodic checks) is more logical to do on the functions of the clipboard itself (OpenClipboard, which is already mentioned in the source code).

 
Stanislav Korotky #:

It explicitly says nothing about manually disabling (or otherwise configuring agents) - and that nuance is still bypassed. This is the very reason I have a question about how much parallel work is automated. I naively thought from the topic and blog description that full automation was done.

Full automation on the MQ side. On any machines, even if working with one terminal, I switch off 1-2 agents so that I can work on the machine without lags.


Terminal1 (Optimisation): Agents 3000-3017 - enabled, 30018-3019 - disabled. So on all terminals, because all other terminals are a full copy of the first one. No manual settings are made.

Terminal2 - for single passes.


Two scenarios.

  1. First I ran optimisation on Terminal1, 3000-3017 were switched on. Then single passes on Terminal2 - 3018 works.
  2. First ran singles on Terminal2, 3000 came on. Then optimisation on Terminal1 - running 3001-3018.
Everything is automated on the MQ side. It's a matter of a minute for you to check it. The dialogue took a lot more time.
 
Stanislav Korotky #:

PS. I probably misunderstand something, but if only exceptional access to the clipboard was required, then it would be more logical to do the same lock (loop with periodic checks) on the functions of the clipboard itself (OpenClipboard, which is already mentioned in the sources).

I don't see the logic in such a solution.

 
fxsaber #:

Full automation on the MQ side. On any machine, even if I work with one terminal, I switch off 1-2 agents so that I can work on the machine without lags.


Terminal1 (Optimisation): Agents 3000-3017 - enabled, 30018-3019 - disabled. So on all terminals, because all other terminals are a full copy of the first one. No manual settings are made.

Terminal2 - for single passes.


Two scenarios.

  1. First I ran optimisation on Terminal1, 3000-3017 are on. Then I ran singles on Terminal2 - 3018 is running.
  2. First ran singles on Terminal2, running 3000. Then optimisation on Terminal1 - 3001-3018 works.
Everything is automated on the MQ side. It's a matter of a minute for you to check it. The dialogue took a lot more time.

If this description was in the blog, there would be no question. Again, this description means manual configuration of agents, imho, not automation. There is nothing to check.

 
Stanislav Korotky #:

If this description was in the blog, there would be no question. Again, this description means manual configuration of agents, imho, not automation. There is nothing to check.

There is no manual configuration. You can do nothing with the agents, the behaviour will not change. Surprising.

 
fxsaber #:

There is no manual configuration. You can do nothing to the agents, behaviour will not change. Surprising.

It was stated "to avoid possible conflicts when working with parallel Testers." This phrase is misleading in the context of cores, because what is actually being done is manual configuration of agents. For some reason you persist in associating port allocation with cores. Ports cannot overlap, but kernels (processes) can - it just depends on the preconfiguration. I suppose we just have different notions of automatic conflict resolution between parallel processes.

 
Stanislav Korotky #:

It was stated "to circumvent possible conflicts when working with parallel Testers." This phrase is misleading in the context of kernels, because in fact manual configuration of agents is done.

You have misinterpreted the word "circumvention". The problem occurs when multiple terminals are working with clipboard at the same time. It used to be that jobs from one terminal could accidentally get into another terminal. Now it is excluded.

 

The following changes are available in MTTester.mqh.

  • GetLastTstCacheFileName now returns the name of the tst file WITHOUT the path.
  • GetLastTstCache has the ability to fetch the tst file that corresponds to the just completed pass. This prevents erroneous tst files from being fetched.
  • ClickStart works correctly even when the Tester reacts instantly when the Start button is pressed. In such cases ClickStart recognises that the Start button was nevertheless successfully pressed.
 

Sometimes you need to do the same thing on working terminals. Automation of this action is shown below on the example.


It is required to collect data on each terminal by running a similar script RunMe.mq5.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/ru/code/26132
  
void OnStart()
{
  if (MTTESTER::LockWaiting()) // If you want to perform actions sequentially.
  {
    const int handle = ::FileOpen(__FILE__, FILE_WRITE | FILE_READ | FILE_ANSI | FILE_COMMON);

    // Write the required data to the file.
    if (handle != INVALID_HANDLE)      
    {
      FileSeek(handle, 0, SEEK_END);
      FileWriteString(handle, "Account = " + (string)AccountInfoInteger(ACCOUNT_LOGIN) + ", " +
                              "Balance = " + (string)AccountInfoDouble(ACCOUNT_BALANCE) + "\n");
      
      FileClose(handle);
    }

    MTTESTER::Lock(false); // Release the parallel execution lock.
  }
}


This is how it is done.

// Run the script on all terminals.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/ru/code/26132
  
void OnStart()
{
  HANDLE Handles[]; 
  
  // Run through all the terminals
  for (int i = MTTESTER::GetTerminalHandles(Handles) - 1; i >= 0; i--)
    MTTESTER::RunEX5("Scripts\\RunMe.ex5", Handles[i], true); // and run the appropriate script on each.
}


As a result, we have collected data from all terminals with one click. Thanks to MTTESTER::RunEX5 - runs EX5 on the required terminal (portable).

1...232425262728293031323334353637...45
New comment