Remote agents are not working in optimisation (a bunch of x86 computers): what to do ? - page 2

 

With the launch of virtual hosting servers for MT5, we have reassessed the state of our services, including the MQL5 Cloud Network.

It's time to reform the settlement network:

  • Get rid of compatibility issues on 32/64 bit systems forever, moving to x64 only
  • Improve the quality of the billing network by rejecting blatantly weak 32-bit agents which lack memory and CPU. Weak agents have long been filtered out when issuing jobs, so eliminating 32 bit agents would benefit the most - they were not very useful anyway
  • Improve network speed, including new methods of optimizing traffic and network latency
  • Raise the cost of settlements by a factor of 2. The old prices at the moment are already quite ridiculous.

 
Is that why the day before yesterday my in-house EAs in the tester stopped working?
 
32 битные тестеры можно использовать только в локальных расчетах.

Would a VPN help with this problem?

I'm not really into the subject, but as far as I understand it, it's some kind of local network built over the internet. Will agents be accessible from such a "pseudo-local" network?

 
Vinin:

The solution is not really a good one.

I, for example, reinstall the system every six months. It's x32 at the moment. Before that it was x64.

And the fact that developers refuse 32-bit system is not good, or rather very, very bad.

Do you often have to reinstall the system, viruses ?
Laryx:

Greetings all.

I updated my terminal today, and what a joy, when I ran TC in MT5 for optimization, I got only two on my local cores instead of my usual dozens of optimization threads.

I understand "need to follow development of IT-industry", but the stock of old computers is still very large, it's very reasonable to use them, but in this case it turns out that I was "cut off" as much as I wanted and I'm offered to "move to 64x" ?

Here, I have my computer (Core 2Duo, Win7, x32), and a network in which only one computer is slightly more powerful, and the rest of the pile of computers, mostly on "fourth" stumps and WinXP. This cluster used to do a pretty good job of optimizing. Now, however, it turns out I only have my two cores.

I would like to ask developers what they suggest me to do. How can I use available computing power?

As far as I understand they propose to scrap all computers?

Isn't it too drastic a decision to drop the x32 architecture so abruptly when there are still a huge pile of x32 computers in operation?

You have 2x core processor, x32 architecture, so the system must crash often ? :) CPU or disk, don't you fear of burning it?
 
Alexey:
Do you often have to reinstall the system, viruses?
You've got a dual core processor, x32 architecture, must be a lot of system crashes? :) CPU or disk, don't you worry about burning it?
Yup, my system also shows processor temp in red when optimizing so i dont use my 8 cores for testing
 
IvanIvanov:
Yep, my system too shows processor temperature in red during optimisation so my 8 cores for testing are not
Do you have an x86 or x64 system
 
Renat:

Unfortunately, support for 32bit testers clearly limits our (developers) future because of compatibility.

At the moment there is no point in supporting 32 bit platforms. Yes, 32 client terminals will still be supported, but advanced services will only be on modern platforms.

In 2015, we must move to x64 operating systems, and even more so, forget about XP. If we are talking about serious work.

Renat, with all my respect to MetaTrader - if we are talking about serious development - we should move to WLD, which also works fine on x32 platforms, and at the same time is a head over heels above MetaTrader as a means of TS development.

I would like to ask - what "advanced" services are we talking about for "serious" DEVELOPERS?

 
Alexey:
Do you often have to reinstall your system, viruses?
You have 2x core processor, x32 architecture, probably the system crashes often? :) CPU or disk, don't you worry about burning it?


Again - there are even single-core Celerons on my network - and none have crashed for several years. And, although each processor is significantly weaker than even my (not at all new) CPU - in terms of number of passes they often do half the total work.

 
Renat:
Get rid of compatibility issues with 32/64 bit systems forever by moving to x64 only
Agreed, less hassle for developers.
  • Improve the quality of the billing network by eliminating the blatantly weak 32-bit agents, which lack memory and CPU. Weak agents have long been filtered out when issuing jobs, so eliminating 32-bit agents would only benefit you - they didn't make much of a difference anyway

I disagree. I have ALL agents that are 32-bit, and they bring very noticeable results

  • Improve network responsiveness, including new methods of optimizing traffic and network latency

Yes, well, while I see optimization speed decrease by more than 10 times.

  • Raise the cost of calculations by a factor of 2. The old prices at the moment are already quite ridiculous.

I find it difficult to assess the usefulness of this chip - I need testers to optimize TC, but not for earnings.

Sadly. I have to admit that I have a lot of problems now.

I wonder how other developers are doing...

 
Renat:

With the launch of virtual hosting servers for MT5, we have reassessed the state of our services, including the MQL5 Cloud Network.

It's time to reform the settlement network:

  • Get rid of compatibility issues on 32/64 bit systems forever, moving to x64 only
  • Improve the quality of the billing network by rejecting blatantly weak 32-bit agents which lack memory and CPU. Weak agents have long been filtered out when issuing jobs, so eliminating 32 bit agents would only serve their own purpose - they were not very useful anyway
  • Improve network speed, including new methods of optimizing traffic and network latency
  • Raise the cost of settlements by a factor of 2. The old prices at the moment are already quite ridiculous.

Will the x32 terminals even remain? Or will they also become a thing of the past in the near future?
Reason: