私のアプローチコアはエンジンです。 - ページ 147

新しいコメント
 

一般的には、ほぼ問題は解決しています。

  1. EAの各コピーは、それ自身の2つのリソースを作成する必要があります。1つはエンジンにメッセージを書き込むため、もう1つはエンジンからメッセージを読み取るためです。
  2. エンジンは、リソースをループして、異なるペアで実行されているEAのコピーの数を確認する必要があります。
  3. エンジンは、実行中のEAの動的なリストを作成し、ユーザーはそれを通じて接続を切り替えます。
  4. 次に、メッセージング用リソースとEAからのメッセージ受信用リソースの名前を記録する。

  1. 各EAは通常通り動作し、通常の方法でエンジンにメッセージを書き込む。エンジンは、そのEAに接続されているときだけ、これらのメッセージを読みます。
  2. エンジンは接続イベントでEAにコマンドを送り、エンジンはリソースに個別パラメータカーネルを書き込む。
  3. エンジンはこのカーネルをロードします。次に、GUIの各要素をループさせ、最新の情報を伝えるように再描画します。
  4. この後、エンジンはメッセージを受信するために、そのリソースのEAにメッセージを書き込むことになります。

現時点では、すべてのEAが1つの共通リソースを通じてエンジンにアクセスします。目標は、各アドバイザーがエンジンと通信するための個別のリソースを持つことです。そして、エンジンは異なるEA用のリソースを再接続できるようになる。
 
例えば5人のアドバイザーが、6人目でエンジンをかけた場合、フルボリュームのワークパッケージが送信されることに戸惑いを感じます。他の5人は、当分の間、仕事の情報発信を禁止すべきです。ただ「電波を聴く」だけにしてください。
 
Oleg Papkov:
例えば5つのEAが、6番目のEAでエンジンを動かしていれば、ワークパッケージの全量を送信することになるので、戸惑いますね。他の5人は、当分の間、仕事の情報発信を禁止すべきです。ただ「電波を聴く」だけにしてください。

私もそう思います。これなら納得です。

そのため、正常に動作しますが、リソースへのメッセージの書き込みはできません。パラメータカーネルのコピーに限る。そして、接続されると、パラメータカーネルがリソースに書き込まれ、エンジンがそれをロードします。接続すると、Expert Advisorはエンジン用のメッセージをメッセージリソースに書き込み始めます。

 

問題は、その接続についてです。

エンジンは、すべてのEAに小さな文字列のアドレスを公開する。同じ認識アドレスのEA内のカーネルが呼び出され、標準のエンジンアドバイザーの動作が自動的に開始されます。エンジンが他のEAに切り替わると、その瞬間に他のEAと同様に、作業していたEAのカーネルをアドレス待ち状態に切り換える。この時点で、すべてのEAが切断され、エンジンはエンジンが必要とするEAのもう一方のアドレスを待っている状態である。

新EAのカーネルが応答し、標準動作の状態になる。次の時間には、エンジンはフィニッシュラインを送信し続け、待機の状態は変化しない。Expert Advisorは、標準的な取引に加え、フローを解析して作業線の終端が現れるかどうかを確認する必要があります。交換パケットの先頭には、エンジンからのパケットを誰に宛てたものかを示す文字列が必要です。制御パケットを受け取ったカーネルは、指定された頻度で自分の状態のパケットを送信し始める。

その他は、EAごとに固有の識別文字列で対応するのを待ちます。切り替えの際、エンジンは現在のEAに終了文字列を送信する。EAは送信を停止し、自身の認識文字列を認識する状態に入るが、これは同時にエンジンとの標準的なやりとりの開始でもある。

 
Oleg Papkov:

問題は、その接続についてです。

エンジンは、すべてのEAに小さな文字列のアドレスを公開する。同じ認識アドレスのEA内のカーネルが呼び出され、標準のエンジンアドバイザーの動作が自動的に開始されます。エンジンが他のEAに切り替わると、その瞬間に他のEAと同様に、作業していたEAのカーネルをアドレス待ち状態に切り換える。この時点で、すべてのEAが切断され、エンジンはエンジンが必要とするEAのもう一方のアドレスを待っている状態である。

新EAのカーネルが応答し、標準動作の状態になる。次の時間には、エンジンはフィニッシュラインを送信し続け、待機の状態は変化しない。Expert Advisorは、標準的な取引に加え、フローを解析して作業線の終端が現れるかどうかを確認する必要があります。交換パケットの先頭には、エンジンからのパケットを誰に宛てたものかを示す文字列が必要です。制御パケットを受け取ったカーネルは、指定された頻度で自分の状態のパケットを送信し始める。

その他は、EAごとに固有の識別文字列で対応するのを待ちます。切り替えの際、エンジンは現在のEAに終了文字列を送信する。EAは送信を停止し、自身の認識文字列を認識する状態に入るが、これは同時にエンジンとの標準的なやりとりの開始でもある。

リソースはもう少しシンプルです。住所は必要ありません、リソース名だけです。もっと複雑なモデルもあるんですね。よりシンプルになりました。

コアは単純に値の配列である。各Expert Advisorは、そのGUI要素のパラメータの値を書き込むことになります。必要に応じて、EAがカーネルパラメータのコピーをリソースに保存し、エンジンがそれを読み込んでGUIを再描画する。

原理的には簡単な作業なのですが、ちょっとしたニュアンスが多いのです。例えば、EAとの通信の開始や停止に関するメッセージなど。あとは形式を考えるだけです。


ちなみに、通信のスピードアップと遅さの減少に成功しました。しかし、その理由はまだわかっていません。再描画時に発生するのですが、不思議なのは再描画自体がブレーキになっていないことです。しかし、リソースと通信する際の再描画が遅くなっています。その理由は、まだはっきりとはわかっていません。

 

タイムコストモニタリングのようなものを入れる。だから、どこが減速しているのかがわかるんです。そして、それを回避する方法。

ちょっと複雑にしすぎたかもしれませんね。エンジン内部がどのように整理されているかは分かりませんが。私は論理的に考えただけです。

 
Oleg Papkov:

タイムコストモニタリングのようなものを入れる。どこが減速しているかを見るため。そして、それを回避する方法。

ちょっと複雑にしすぎたかもしれませんね。エンジン内部がどのように整理されているかは分かりませんが。私は論理的に考えただけです。

ロジックはポイントに近づき、一般的には正しく理解されましたね。

今日は、ブレーキングの原因を突き止めてみようと思います。次のことは明らかです。再描画そのものが遅くなっているわけではありません。リソースの書き込み、読み出しも遅くはない。しかし、共に遅さを手に入れる。

 
モニターがありますが、どの動作がどのくらい続くのでしょうか？順次実行する必要があります。EAでは、データを取ってエンジンに送るという作業を、例えば30msの頻度で行っています。スレッドがエンジンに送られたとき、受信できる状態になっているか？あるいは、何をするものなのか？
 
Oleg Papkov:
モニターがありますが、どの操作にどれくらいの時間がかかるのでしょうか？これらは、順次実行する必要があります。Expert Advisorはそれらを実行し、データを取り込み、例えば30msの頻度でエンジンに送信する。スレッドがエンジンに送られたとき、受信できる状態になっているか？あるいは、何をするものなのか？

今、すべてをチェックする。

30msでエンジンがEAからメッセージリソースを読み出し、同じ頻度でEAがエンジンからメッセージリソースを読み出す。同じ周波数で、お互いにメッセージを書く（書くべきことがあれば）。これだけで、動作が遅くなることはありません。また、再描画そのものが、ブレーキをかける原因にはなりません。

しかし、Engine側で再描画とリソースの書き込み/読み出しが重なると、速度低下が現れる。この原因はまだ明らかではありません。把握すること。

 
Реter Konow:

今、すべてをチェックする。

30msでエンジンがEAからメッセージリソースを読み出し、同じ頻度でEAがエンジンからメッセージリソースを読み出す。同じ周波数で、お互いにメッセージを書く（書くべきことがあれば）。これだけで、動作が遅くなることはありません。また、再描画自体は、ブレーキがかかることはありません。

しかし、Engine側で再描画とリソースの書き込み/読み出しが重なると、速度低下が現れる。この原因はまだ明らかではありません。確認中です。

EAとエンジン、1-両方がお互いにパス、2-両方が受信、それらのOnTimerサイクルが同期していない、というミスマッチがあるかもしれません。ランダム同期の瞬間が正常に動作するのを待ちます。これが理由でしょうか？

1...140141142143144145146147148149150151152153154...184
新しいコメント