AUDCAD : real ticks begin from 2020.07.1500:00:002020.07.1500:01:09 buy limit 1 AUDCAD at 0.84993 (0.94914 / 0.94993)
2020.07.1500:01:09 market buy 1 AUDCAD (0.94914 / 0.94993)
2020.07.1500:01:09 deal #2 buy 1 AUDCAD at 0.94993 done (based on order #3)
2020.07.1500:01:09 deal performed [#2 buy 1 AUDCAD at 0.94993]
2020.07.1500:01:09 order performed buy 1 at 0.94993 [#3 buy 1 AUDCAD at 0.94993]
2020.07.1523:59:58 position closed due end of test at 0.94646 [#3 buy 1 AUDCAD 0.94993]
2020.07.1523:59:58 deal #3 sell 1 AUDCAD at 0.94646 done (based on order #4)
2020.07.1523:59:58 deal performed [#3 sell 1 AUDCAD at 0.94646]
2020.07.1523:59:58 order performed sell 1 at 0.94646 [#4 sell 1 AUDCAD at 0.94646]
2020.07.1523:59:58 order canceled due end of test [#2 buy limit 1 AUDCAD at 0.84993]
final balance 99999653.00 pips
2020.07.1523:59:58 CheckTicket(4) = true2020.07.1523:59:58 CheckTicket(3) = true2020.07.1523:59:58CheckTicket(2) = false
Глобальные переменные создаются путем размещения их объявлений вне описания какой-либо функции. Глобальные переменные определяются на том же уровне, что и функции, т. е. не локальны ни в каком блоке. Область видимости глобальных переменных - вся программа, глобальные переменные доступны из всех функций, определенных в программе...
スナップショットのデバッグに疲れました。ようやく完璧になった。アドバイザー1名、何もなし。2 - 完璧です。20 - 災害時:CPUが100%未満です。HistorySelectは何ミリ秒もの遅れがある。
MT5は、多くのExpert Advisorを同時に操作することを想定していないようです。
ストレステストや 通常のExpert Advisorを書いているのですか?
最も可能性が高いのは、まさにシングルベースにおけるマルチスレッドのストレステストです。だから、繰り返し言います。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MT5とスピードの関係
レナート・ファットフーリン さん 2020.09.16 12:47
私の理解が正しければ、そこにはEAがあるわけではなく、各シンボルにストレステスターが あるのです。これでは、まったくケースが変わってしまいます。そして、初期条件の隠蔽を示す。
つまり、8(4+HT)CPU上で16スレッド(+Nワーカー端末スレッド並列)がノンストップで遅延なく1つの同期されたシンボルデータベース・オブジェクトにブレークするのです。常にティック書き込みがあるため、Read/Writeロックが混在している。
通常、このようなプロファイルでは、プロセッサの急勾配とスレッドの使い方によりますが、各スレッドは60%から80%の待ち時間を費やすことができます。
そして、これはタスクの種類に関係なくです。
実際に20スレッドで1リソースの争奪戦をノンストップで行っている場合、いくつかのオプションがあります。
箱をよく読んでください。N個のスレッドが1つの同期オブジェクトにヒットした場合、空の待ち時間は60~80%になります。
そして、マルチスレッドの効率の限界は、8〜12スレッドあたりになるでしょう。スレッド数が増えると、サンプリングレートが下がります。2600kでは、効率の限界はさらに低くなります。
ストレス テストを書いているのか、普通の専門家の仕事なのか?
普通
むしろ、1つの基盤でマルチスレッドのストレステストができる。だから、繰り返す。
もし、実際に20スレッドで1つのリソースを奪い合うノンストップバトルを行っているのであれば、いくつかの選択肢があります。
箱をよく読んでください。N個のスレッドが1つの同期オブジェクトにヒットした場合、空の待ち時間は60~80%になります。
そして、マルチスレッドの効率の限界は、8〜12スレッドあたりになるでしょう。スレッド数が増えると、サンプリングレートが下がります。2600kでは、効率の限界はさらに低くなります。
履歴を完全にキャッシュする。しかし、これでもHistorySelect(0, INT_MAX)を呼び出す必要があります。
試しに、取引ロジックに必要なヒストリーの呼び出しをすべてカットしてみました。CPUへの負荷が非常に減りました。
一般的に、ロボットが20台あるとすると、履歴を全部呼び出すと、たった1台の端末で大惨事を引き起こす可能性があるということです。いくつかの端末については、私たちも話すことができません。
そして、シンクロオブジェクトは歴史だけではないと感じています。SymbolInfoTick、CopyTicksと何か違うようです。
とにかく、5台の端末に12台のロボットを搭載しても、稼働させることができないんです。
ブレーキングプロファイラーを見ると、げんなり します。
普通
履歴を完全にキャッシュする。しかし、これでもHistorySelect(0, INT_MAX)を呼び出す必要があります。
実験として、取引ロジックに必要なヒストリーコールを全てカットしてみました。CPUへの負荷が非常に減りました。
一般的に、ロボットが20台あるとすると、履歴を全部呼び出すと、たった1台の端末で大惨事を引き起こす可能性があるということです。いくつかの端末については、私たちも話すことができません。
そして、シンクロオブジェクトは歴史だけではないと感じています。SymbolInfoTick、CopyTicksと何か違うようです。
とにかく、5台の端末に12台のロボットを搭載しても、稼働させることができないんです。
ブレーキングプロファイラーを見ると、げんなり します。
根拠も数値データもない。
1) 各EAは1秒間に何回HistorySelectのクエリーを行うのですか?
2)具体的にどの機能が遅くなっているのでしょうか?
3)ログは?
4)ロボットの原理は?
20台のロボットがあるとすれば、その中のストーリーに対応することは、たった1台の「ターミナル」で災害を引き起こすことになるのです。複数端末は論外。
逆に、各ターミナルが独自のシンクロオブジェクトをサポートし、それに対する20のEAのキューが存在しなくなるのかもしれませんね。
1台の端末で1台のロボットを動かしてみると、面白い結果が得られるでしょう。
もしかしたら逆に、各ターミナルが独自の同期オブジェクトをサポートし、それに対する20のEAのキューが存在しなくなるかもしれませんね。
1台の端末で1台のロボットを動かしてみると、面白い結果になります。
残念ながら、この実験の結果では、どうすればいいのか、という問いに答えることはできない。
残念ながら、この実験の結果では、どうすればいいのか、という問いに答えることはできない。
トレーディングロボットの概念を見直す
追加
実機3台+デモ1台で作業しています。
各端末には、3文字から4文字のOnBoorEventを使用するロボットが42台設置されています。
さらに0.5秒ごとにタイマーが作動し、各ロボットは端末のグローバル変数に アクセスする。
で、32GBのRAMのうち8.34GB、CPUの6.7%を使用します。
そして、取引開始時のTM5サーバーを除いては、何も遅くなることはありません。
根拠もなければ、数値データもない。
1) 各エキスパートは、1秒間に何回HistorySelectクエリーを行うか?
2)具体的にどの機能が遅くなっているのでしょうか?
3)ログは?
4)ロボットの原理は?
何が減速しているのか、私自身でも把握できていないので、この質問に答えるのはとても難しいです。プロファイラも起動しない。彼らの測定は、ラグがすでにCPUから発生しているため、ごまかしがきかないのです。スナップショットやキャッシュによる環境関数のアクセス低減は、残念ながら期待通りの効果が得られませんでした。Expert Advisorをコンパイルできるプロファイラーを待っています。
忙しい中、Strategy Testerの取引履歴でこんなゴタゴタがありました。
その結果
このバグにほとんど気づかず、1時間以上リプレイを書き込もうとしています。コードはモロバレですが、問題を示しています。Testerではなく、Terminalに同じようなものがあるのかどうかは分かりませんが。
検索文字列:オシブタ013。
ZS b2626 - 修正しました。
トレーディングロボットのコンセプトを再考する
全てのシンボルを取引するロボットは1台だけ?
全てのシンボルを取引するロボットは1台だけ?
ロボットは違っても、ほぼ同じパターンで作られています。
1つの端末に関わる仕事は一度に42件、3件では126件と約400件のシンボルがあります。
追加
繰り返すこと(私)
各ロボットは3文字から4文字までのOnBoorEventを使用します。
さらに0.5秒ごとにタイマーを起動し、各ロボットは端末のグローバル変数にアクセス する。
32GBのRAMのうち8.34GB、CPU使用率は6.7%。
そして、取引セッションの開始時にTM5サーバー(またはOpenreachのハードウェア)以外、何も遅くなることはないのです。
ロボットは違っても、だいたい同じような仕組みで作られています。
1つの端末に一度に関わるジョブは42個、3つでは-126個で約400文字です
追加
繰り返すこと(私)。
各ロボットは3文字から4文字までのOnBoorEventを使用します。
さらに0.5秒ごとにタイマーを起動し、各ロボットは端末のグローバル変数にアクセス する。
32GBのRAMのうち8.34GB、CPU使用率は6.7%。
そして、取引セッションの開始時にTM5サーバー(またはOpenの鉄)を除いて、何も遅くなることはないのです。
ここで不思議なことに、私の場合は逆なんです。
私の端末は4端末で、Expert Advisorの数を200程度に減らし、OnBooksを全てカットしてOnTickに戻し、ハードウェアも更新しましたが、問題はfxsaberと同じです。
しかし、私のOpenerではもうずっと朝のラグがありません。そして、かつてはどうだったのか!?最大75秒の場合もあります :)