エラー、バグ、質問 - ページ 2963

[Nikolai Semko]

fxsaber:

そして、Indicator1とIndicator2を何らかの方法で同期させ、両方の数値を同じ共通線に書き込めるようにする必要がある。

これは非常に複雑なソリューションです。

user32.dllが同期をとってくれます。
主な内容は、各番号が一意の番号を持ち、この番号がデータ配列のインデックスとなるように、正しく番号を付けることです。
これは、最後の手段として、手動で行うことができます。あるいは、自動で行うことも可能です。ちなみに、最近KB（Indicator Cases）でも似たようなことを発表しています。
資源の何がいけないのか？1つの端末の範囲内で最適だと思います。私が提案するバリアントは、user32.dllを使用し（10年ほど前、若かりし頃、裁定取引に手を出した時に実装しました）、アクセス時間、データ解析は50マイクロ秒程度（1.5～2倍で高速化可能かと思います）です。リソースを使うともっと遅くなるのか？

[fxsaber]

Nikolai Semko:

user32.dllが同期をとってくれます。

書いてみてください。おそらく、その課題を十分に理解していないのでしょう。

なぜリソースが嫌いなのか？一つの端末の範囲内で最適だと思います。私が提案したuser32.dllを使った亜種（10年ほど前、若かりし頃裁定取引に手を染めていた頃に実装しました）は、アクセス・解析時間が50マイクロ秒程度（1.5～2倍は高速化できると思います）です。リソースを使うともっと遅くなるのか？

家庭用マシンでは理想的な条件下で100マイクロ秒の読み取り時間を要します。1ティックのExpert Advisorで100回読みが発生することがあります。遅いんですよ。

理想的な条件では、GlobalVariableGetは 10マイクロ秒で実行されます。しかし、それは指標にはならない。初めての戦闘状況下では、恐ろしいほどのブレーキになるのだから。

[Andrey Khatimlianskii]

fxsaber:

これは、HistoryTicks - EAのすべてのティックをキャッチします。したがって、EventChartCustomは適しておらず、独自のキューを持っています。それは、バッファも同じです。

EventChartCustomで動作させています。0.15ms以内に99.8%のティックを受信することができます。

トレーディング、自動売買システム、ストラテジーテストに関するフォーラム

EventChartCustom => インジケータが遅すぎる

アンドレイ・ハチムリアンスキー 2019.12.12 09:27

5つのシンボルを使って9時間作業した場合の統計です。

Windows 8.1 (build 9600) x64, IE 11, UAC, Intel Core i5-3570  @ 3.40 GHz, Memory: 6979 / 16346 Mb, Disk: 341 / 499 Gb, GMT+2

[USDCHF]: 22784 of 22833 (99.8 %) ticks were processed (0.14 ms delay in average), 49 (0.2 %) ticks were skipped (103.4 ms delay in average)
[EURUSD]: 22944 of 22974 (99.9 %) ticks were processed (0.16 ms delay in average), 30 (0.1 %) ticks were skipped (115.6 ms delay in average)
[USDCAD]: 15331 of 15347 (99.9 %) ticks were processed (0.13 ms delay in average), 16 (0.1 %) ticks were skipped (104.6 ms delay in average)
[EURCHF]: 22516 of 22571 (99.8 %) ticks were processed (0.13 ms delay in average), 55 (0.2 %) ticks were skipped (127.8 ms delay in average)
[EURAUD]: 66842 of 66924 (99.9 %) ticks were processed (0.13 ms delay in average), 82 (0.1 %) ticks were skipped (117.8 ms delay in average)
[GBPUSD]: 41393 of 41393 (100.0 %) ticks were processed (0.00 ms delay in average)
Total trade requests time: 4.280 sec

Expert AdvisorはGBPUSDのものだったので、ネイティブのOnTickが動作しました。

インジケータが遅すぎる」というエラーはなかった。

一方、MQのVPSでは ミスティックの割合や平均レイテンシがかなり高くなっています（後日、統計データを掲載します）。
そして、「インジケータが遅い」というエラーが多発します。

Expert Advisor は蓄積されたイベントをすぐに処理する（戻るだけ）ので、キューのオーバーフローの本質が理解できません。
加工している人はいるのでしょうか？

[fxsaber]

Andrey Khatimlianskii:

EventChartCustomで 動作させています。0.15ms以内に99.8%のティックを受信することができます。

Sparam contains MqlTick, lparam - tick number.私はこの方法でインジケータからティックを送信しています。

OnChartEventの Expert Advisorは、これらのティックをキャッチします。そして、現在のティックが最も実際のものであるかどうかを理解する必要があるのでしょうか？すなわち、ティックのキューがあるのか、それとも空なのか？

そのために、インジケータが送信した最新のティックの番号（タスクはこの番号を読み取ることです）を読み取ります。ティックが同じ番号であれば、キューは空で、ティックを使って作業を開始することができます。

また、OnTickの動作中、OrderSendの後に、インジケータがさらにティックを送信したかどうかをチェックする必要があります。そのためには、再びインジケータから数値を読み取る必要があります。また、1つのOnTickの間に、このようなチェックが100以上行われることもあります。だからこそ、速読が必要なのです。

[traveller00]

1ターミナル以内では、最速のwinapiは、メモリ割り当て（プロセス内のグローバル）と、https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange のような連動した関数になるでしょう。

これらは、ノンブロッキング、アトミックで、基本的にいくつかのasm命令で実行されます。

[fxsaber]

traveller00:

1ターミナル以内では、最速のwinapiは、メモリ割り当て（プロセス内のグローバル）と、https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange のような連動した関数になるでしょう。

これらは、ノンブロッキング、アトミックで、基本的にいくつかのasm命令で実行されます。

例がないわけではありません。

[traveller00]

fxsaber:

そのために、インジケータが直近に送信したティックの番号（この番号を読み取ることがタスクとなります）を読み取ります。受信したティックが同じ番号であれば、キューは空で、ティックのパックで作業を開始することができます。

また、OnTickの動作中、OrderSendの後に、インジケータがさらにティックを送信したかどうかをチェックする必要があります。そのためには、再びインジケータから数値を読み取る必要があります。また、1つのOnTickの間に、このようなチェックが100以上行われることもあります。ですから、早く読む必要があるのです。

初期化する。

1.最初のスレッド（最も可能性が高いのは書き込みスレッド）で、必要なサイズの変数に何らかの方法でメモリを確保します。

2.必要なスレッド（読み込みスレッド）において、このメモリのアドレスを送信する。

基本的な作業です。

3.書き込みスレッドは、書き込みのための変数サイズに応じてInterlockedExchangeまたはInterlockedExchange64を開始する。

4.読み出しスレッドは、InterlockedCompareExchangeなどを引き出して読み出す。

完成です。

5.割り当てられたメモリを 解放する。できれば割り当てたスレッドと同じスレッドで解放する。

必要であれば、複数のカウンターを作成するために繰り返すことができます。欠点としては、WinAPI接続が必要になることです。割り当てられたメモリアドレスの特徴のうち、アライメントされるべきですが、デフォルトでは通常そうなっています。

作業は1プロセス内で行い、メモリは1プロセス内のスレッドで共有します。必要であれば、InterlockedDecrement、InterlockedAddなどの他の連動関数も存在する。

関数は、ノンブロッキング、何も待たない、オートマタ、それらはいくつかのasm命令で実行されます。

追伸：私の記憶では、アセンブラのmovによる通常の読み書きの操作は、とにかくアトミックです。そして、コンパイラが混乱しなければ（理論的には混乱しないはず）、割り当てられたメモリ内の変数に読み書きしてみれば、アトミックになるのです。

タスクに合ったものであれば、1工程内で速くなることはまずないでしょう。プロセス間でも最速は同様ですが、共有メモリを使用するため、この場合はWinAPIがないと無理です。

[Roman]

fxsaber:

この方式はうまくいかないようです。初歩的な例を示してくださいよ。

なぜ実行可能でないのか？ただ、私が思うに。ゲッターセッターの原理。
関数で隠し変数の値を取得すること。
MqlTick構造 体を渡す場合は、MqlTickのようにフィールドを設定した構造体を定義し、構造体にカウンタフィールドを追加してください。
そして、この構造体をエクスポート関数から返します。
インジケーターの初歩的な例です。スクリプトの例には注意を払わないでください。

struct myMqlTick 
{ 
   datetime     time;          // Время последнего обновления цен 
   double       bid;           // Текущая цена Bid 
   double       ask;           // Текущая цена Ask 
   double       last;          // Текущая цена последней сделки (Last) 
   ulong        volume;        // Объем для текущей цены Last 
   ulong        count;  //Свой счётчик
   
}myStruct;

//--------------------------------------------------
myMqlTick GetTickStruct() export
{
   
   return(myStruct);
}

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
{
   myStruct.time   = 0.0;
   myStruct.bid    = 0.0;
   myStruct.ask    = 0.0;
   myStruct.last   = 0.0;
   myStruct.volume = 0;
   myStruct.count  = 1;  //свой счётчик  
  
}
//+------------------------------------------------------------------+

Expert Advisor では、GetTickStruct を呼び出して、カウンターを含む構造体全体を取得します。

[fxsaber]

Roman:

Expert Advisor で GetTickStruct を呼び出すと、構造体全体とそのカウンタが取得されます。

インジケータからEAへの 初歩的な数値移行の記述をお願いします。

[Roman]

fxsaber:

インジケータからEAへの 初歩的な数字の移し替え、書いてください。

構造体を1つの変数に置き換える ))