PF 0 MQL5 Cloud Europe 200:24:16 genetic pass (264, 0, 188) started
JL 0 MQL5 Cloud Europe 200:29:07 connection closed
ID 0 MQL5 Cloud Europe 200:29:07 connecting to 3.agents.mql5.com:443
GL 0 Tester 00:29:07 cloud server MQL5 Cloud Europe selected for genetic computation
KO 0 MQL5 Cloud Europe 200:29:07 connected
JP 0 MQL5 Cloud Europe 200:29:10 authorized (server build 696)
RG 0 Tester 00:30:11 Best result 32.12073652718463 produced at generation 20. Next generation 21
KJ 0 MQL5 Cloud Europe 00:30:11 common synchronization completed
GN 0 MQL5 Cloud Europe 01:57:24 connection closed
CI 0 MQL5 Cloud Europe 201:57:24 connection closed
MS 3 Tester 01:57:24 genetic pass (21, 285) not processed and added to task queue
II 3 Tester 01:57:24 genetic pass (21, 498) not processed and added to task queue
PO 3 Tester 01:57:24 genetic pass (21, 499) not processed and added to task queue
GQ 0 MQL5 Cloud Europe 01:57:24 genetic pass (21, 285) returned to queue
NF 0 Tester 01:57:24 genetic pass (21, 499) already processed
KN 0 Tester 01:57:24 genetic pass (21, 498) already processed
OJ 0 Core 101:57:24 genetic pass (285, 0, 1) started
PS 0 Core 201:57:24 genetic pass (285, 0, 1) started
8コアで24エージェント（本来は4＋ハイパートレーディング）だと、CPUの性能をすべてインフラの提供に使ってしまいそうで怖いですね。
過剰にエージェントを露出させると、PRパフォーマンス指数が極端に低下し、結果的に料金の倍額になる。
しばらくクラウドを利用していない。パラメータの選択で使用することを決定。クラウドの仕事は、気持ちのいいものでした。
分散型ネットワークシステムを長く挽けば、それなりの結果が得られる。
全部で1時間半はありえない。
P.S.クラウドをオンザフライで回す。インターネットが使えなくなったため、遠隔地のエージェントが脱落。その後、接続しようとしませんでした（自動化された状態。少なくとも2つの遺伝子世代が接続しませんでした）。どうやら、テスターはクラウド上でやることが十分あると判断し、フリーエージェントを休ませたようです。クラウドを切り離す。リモートエージェントが接続されました。クラウドの電源を入れ直した。掛け持ちで終了。
このような事態を避けるために、ネットワークは少し最終化する必要がある（例えば、最大通過時間を記憶し、通過待ちが最大通過時間の2倍長くなった場合、ローカル（またはリモート）から最適なコアで同じプロセスを開始する）。
+TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) を改良する必要があります。
+ 私のコアのPRが160-180で、クラウドのタスクが100までのコアに分配される場合です。その結果、毎世代、私のコアはかなりの時間アイドル状態になり、新しい集団を生成するためにクラウドからの応答を待たなくてはならなくなりました。100PRの制限をなくし、PRが最も弱い ローカルコア（接続されている場合はリモートコア）のPRより 大きいエージェントを最優先するべきだと思います。そうでない場合は、何らかの方法でロードバランシングを行う必要があります。例えば、すべてのパスが同じコアで同じ速度で実行されると仮定した場合（生活では、もちろん、そうではありませんが、いくつかの仮定と多くの専門家は、パラメータに関係なく、テスト時間で安定して呼び出すことができます）。ローカルコアのPRが150、クラウド上のコアのPRが100の場合、ローカルエージェントにはクラウド上のエージェントよりも1.5倍多くのタスクが与えられるべきである。あるいは、PRが低い場合は、クラウド上のエージェントに1つずつタスクを与えるのではなく、1つのタスクをより多くのエージェントに与えるようにします。この場合、ダウンタイムは最小限となる。総じて、この問題については進展を期待したい
この12時間で、ネットワークはさらに3回ハングアップしました :(
(また、遺伝学雑誌でPR < 100の薬剤もある）。
ところで、ssdでエージェントを共有することを試された方はいらっしゃいますか？タスクがなくても8エージェントでドライブがカリカリになることを考えると、ssdのリソースがすぐに枯渇してしまうのではと疑っています。また、かなり軽いEA、コンピュートスピードをテストすると、ハードディスクのスピードが落ちてくるんです。何テラバイトをキャッシュに送り込んでいるかは、いい質問だ)
そのようなアルファベット（ssdのことです）がありますが、具体的なテストはしていません：そのようなデバイスを搭載したサーバーが街の反対側にあるためです。しかし、IMHOは、どんなシステムでもディスクキャッシュがあり、ディスクへの頻繁なアクセスをスムーズにする。
私は、2つのペアのすべてのティックにシンプルなグライダー（タイマー30秒、新しいm1バーコントロール）を最適化することにしました。私の4コアi5（PR=160-170）と8コアi7（PR=170-180）は約90時間（！）最適化されました。
そして、i5の通路は2倍遅くテストされることが判明した（ただし、すでに何度か書いたように、その逆で、i5＋winxp64はi7＋win7x64より速かった）。最初はメモリを刈り取りました。i7はもっと多いんです。
そして、うっかりタスクマネージャーをチラ見したら、エージェントの優先順位が一番低い（Low）になっていました。しかも、両方のマシンに搭載しているんです。また、win7ではなんとか優先順位をNormalに上げることができましたが、winxp64bitではなぜかそれができないのです。i7で新しい優先順位をつけた半日で、私のテスト時間は数時間短縮された（ように見える：）。
このような「遅れ」は、最近の2つのビルドで観察されるようです（あるいは、私だけがそう感じているのかもしれません）。
そして、プライオリティ・ローはあまりにも残酷です。もし、1日あたり少なくとも12時間の機器が、エージェントに最大の優先順位を与えることができます。
一般的には、リソースの負荷に応じて優先度が何らかの形で自動的に変わると思っていたのですが、どうやら勝手に変わることはないようです :(