Chatter about the MT5 strategy tester - page 11

[Yuriy Zaytsev]

Andrey Dik:

You're talking about the shared folder C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.

The same principle is needed for terminal in normal mode and not with forced specification of shared folder to history bases by means of links. Now it works fine, but please implement this feature normally by specifying a folder to history bases in the terminal settings.

:-)

I've already made a request, to spread the sandbox with data files and logs over the disk system for speedy performance.

For example there is an SSD drive, one for the system, SSD for logs, SSD for quick data.

Well, it would be good if logs on one SSD , data on the other - the terminal itself where may be too on the SSD

Data access speed will increase, taking into account that each drive has its own controller.

you talk about something else - for access to a common database - to collect data from one dilling for different terminals in one folder - how many people have such a configuration?

I've just bought 12 terabytes of hard drives and forgot the problem - hard drives are so big now that it's not relevant.

[Renat Fatkhullin]

Andrey Dik:
No, what Andrew is suggesting is that the developers make public folder access a regular feature. That's exactly what he is suggesting, this is an appeal to you, not to millions of traders.

An explanation has been given:

• No one will make a bottleneck in the form of a server (and a single database means an access manager. And this manager cannot be a file system with locking access - everything will slow down fabulously)
  
• nobody is going to do a write bottleneck in the system
• nobody will run tens of gigabytes of data (and it is tens of gigabytes) through a bottle-neck
  
• the behavior of tester agents is reasonable - they will use a synchronized read-only database
  
• all at the altar of speed and low latency
  

The current architecture is very good, fast and secure. We wrote the fifth generation of trading platforms for a reason - we know the value of each solution.

[Vasiliy Sokolov]

Renat Fatkhullin:

• No one will make a bottleneck in the form of a server (and a single base means an access manager. and this manager cannot be a file system with access blocking - everything will be fabulously slow)

As a result, application programmers write those very file managers with access blocking and fabulous brakes, because there is no other solution in MQL. But their souls are warmed by magical "latency" and other mantras of theoretical performance, which are hard to apply in practice.

[Renat Fatkhullin]

Vasiliy Sokolov:
Right. As the result, application programmers write those file managers with access blocking and fairy tale brakes because there is no other solution within the framework of MQL. But their souls are warmed by the magic "latency" and other mantras of theoretical performance, which are hard to apply in practice.

Yes - https://www.mql5.com/ru/docs/globals/globalvariablesetoncondition

The function provides atomic access to a global variable, so it can be used to organise mutex when multiple EAs are working simultaneously within the same client terminal.

And if synchronization between terminals is necessary, there are plenty of options. Even on files, but via DLL mutexes etc. That's your job now, since you're out of the security sandbox.

Without our battle for speed you would have a completely different class of software. The good stuff is not visible, it seems free and self-evident.

[TheXpert]

Vasiliy Sokolov:
Yeah. As a result, application programmers write those very file managers with access blocking and huge brakes, because there is no other solution within MQL.

It all makes sense to me. If you want multiterminal capabilities, make them yourself, but it's a bit, er, irrational to do it for two and a half people.

Moreover, in the vast majority of cases, these problems can be solved in one or two.

And if we're talking about two and a half people, more people need the custom story.

[Andrey Dik]

Yuriy Zaytsev:

Is this a challenge?

Only one gun will be loaded ? :-)

You have been told that you need to create a manager of access to data from different terminals!

And what is the problem with access of different terminals to different data! No problem, but it's convenient if all the files are in one place and there is no need to download data each time when relocating/reinstalling the terminal. But developers don't want to do this either. You don't need access manager for that.

I was talking about 2-3 terminals accessing the same data. There is no problem with this, it is enough that the terminals understand that someone is already writing and do not try to write. And when reading should be no problem at all.

You have no desire to read, understand or argue. I have no desire to throw beads behind it. I know a crutch solution (since developers do not want to make regular features) - I am satisfied with it.

[Yuriy Zaytsev]

xxz:
And the file 2016.hcc should theoretically never be updated.

Renat Fatkhullin:

An explanation is given:

• No one will build a bottleneck in the form of a server(and a single base means an access manager. And that manager can't be a locked file system - everything will slow down fabulously)
  
• no one will make a bottle-neck in the system for recording
• nobody will run tens of gigabytes of data (and it is tens of gigabytes) through a bottle-neck
  
• the behavior of tester agents is reasonable - they will use a synchronized read-only database
  
• everything is on the altar of speed and low latency
  

The current architecture is very good, fast and secure. We didn't write the fifth generation of trading platforms for nothing - we know the cost of each solution.

I'm well aware of that...

because I've had the privilege of developing operating systems and drivers for them.

[Artyom Trishkin]

xxz:

I can't understand you at all!

Why are you turning into a fool!

It is a simple task to make files like "2017.hcc" publicly available within one broker

which, as I now understand, are updated once every "five years".

What is the problem here?

Watch your language and culture of speech please. This is a technical forum.

[Artyom Trishkin]

Andrey Dik:

Yuriy Zaytsev:

Friends, stop squabbling. Removing the flood.

[Andrey Dik]

Artyom Trishkin:
Friends, enough of the squabbling. I'm deleting the flood.

No no, don't delete Yuri's words. He claims that the terminal writes to the file on every tick! This is an accusation of unprofessionalism by MQ, I want to see what Renat, to whose words Yuri refers, will do with it. Don't deny me the pleasure of enjoying the spectacle to come.