SL/TP注文の受付 - ページ 4 12345678 新しいコメント fxsaber 2020.11.30 21:26 #31 Enrique Dangeroux: https://www.mql5.com/ru/forum/341117 は現在も問題になっている 前回、この問題は言及されたブローカーで解決されました。 fxsaber 2020.12.04 09:51 #32 開発者の皆様、アーキテクチャに関する以下の質問にお答えください。戦闘用のアプリケーションに必要な情報です。ノークレーム。 同じ価格でロットの異なる2つの指値があります。起動トリガーの順番はどうなっているのでしょうか？ この問いには、いくつか答えがあります。 敷地内に チケット番号について。 始値の 最終修正から。 注文の最後の変更から（例えば、Limit注文でTake Levelが更新された場合）。 もし私の理解が正しければ、始値を変更した後、そのリミッターはサーバーのすべてのリミッターのリストテーブルに適切に挿入され、始値でソートされることになるのです。そうすると、質問の答えは、同じ価格の注文のリストの最初に埋め込まれているのか、最後に埋め込まれているのか、ということになる。 同じ質問は、制限ではなく、トークンのことです。同一のテイクをトリガーする順番は、何に依存するのでしょうか？IDポジションか何かでしょうか？ これが戦闘にどう役立つかを説明しよう。例えば、同じレベルのリミッター（またはポジションティー）を2つ持っているが、ロットが異なる。リミット（ティー）の実行が最後の修正に依存するのであれば、ロットを上げることでリミッターを修正するだけでFillRateを上げることができますね。 おそらく、対応するMT5サーバー部分の実装を書いた人でないと、この答えはわからないと思います。 secret 2020.12.04 18:43 #33 Andrei Trukhanovich:ブローカーと連携し、ボトルネックを発見する なんだ、ミツバチ対ハチミツか（笑) Andrey Khatimlianskii 2020.12.04 21:25 #34 fxsaber:同じ価格でロットの異なる2つの指値があります。起動トリガーの順番はどうなっているのでしょうか？この問いには、いくつか答えがあります。 敷地内に チケット番号について。 始値の 最終修正から。 注文の最終修正から（例えば、指値でテイクレベルが更新されたなど）。 バリアント4は4作目で使われたような気がします。つまり、何らかの修正があれば、その注文は対応する価格水準の待ち行列の最後尾に移動したのである。 Andrei Trukhanovich 2020.12.04 21:35 #35 secret: ミツバチ対ハチミツみたいなもんかな？) この瞬間に、この状況で、お互いに利益があり、それが実現した。 fxsaber 2020.12.09 00:28 #36 MT5のTP注文は、FillRate（注文のどの部分が満たされたか）を調べることができるのが特徴です。 このような数万件の注文を分析した結果、FillRateはシンボルに非常に大きく依存することがわかりました。TP注文のパックが同時にトリガされた場合、パック内の注文数が増えるにつれてFillRateが減少します。 その他、具体的なニュアンスも明らかになった。しかし、これはすでにブローカーと話し合っている。 FillRateを増やすためのレシピ：同じティックとリミッターを1つの共通のMT5リミッターにまとめる。 しかし、このデータはこの話題のオマケに過ぎない。ブローカーに依存しない問題は、MT5がティックで遅れ、その結果、保留中の注文（SL/TPレベルを含む）の受付で遅れをとっていることです。 そしてリダイレクト後、MT5は次のティックまで毎回待機し、価格がTPレベル（またはリミット）を満たすかどうかをチェックします。最大で数秒かかることもあります。また、チェックは必ずリジェクト（またはパーシャルフィル）の直後に行う必要があります。 ファイル: CheckOrders2.mq5 10 kb fxsaber 2020.12.11 08:17 #37 fxsaber:OnTickは、ティックがトレードサーバーに書き込まれるより数ミリ秒後にトリガーされます。 // Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал. // Запускать на той же машине, на которой установлен MT5-сервер. #include <WinAPI\WinAPI.mqh> input int inPeriod = 10; // EMA-period input int inAmount = 100; // Количество тиков для анализа // Локальное время в миллисекундах. long TimeLocalMsc() { SYSTEMTIME SystemTime; kernel32::GetLocalTime(SystemTime); MqlDateTime time; time.year = SystemTime.wYear; time.mon = SystemTime.wMonth; time.day = SystemTime.wDay; time.hour = SystemTime.wHour; time.min = SystemTime.wMinute; time.sec = SystemTime.wSecond; return((StructToTime(time) * 1000 + SystemTime.wMilliseconds)); } double EMA = 0; int MaxValue = 0; int MinValue = INT_MAX; int Amount = 0; void OnTick() { static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения. MqlTick Tick; const long time = TimeLocalMsc(); // Локальное время в миллисекундах if (SymbolInfoTick(_Symbol, Tick)) { const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика. MaxValue = MathMax(Value, MaxValue); // Максимальное значение. MinValue = MathMin(Value, MinValue); // Минимальное значение. EMA += (Value - EMA) * Alpha; // Среднее значение if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим. { #define TOSTRING(A) #A + " = " + (string)(A) + "\n" Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) + TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST))); ExpertRemove(); } } } 結果 Amount = 100 MinValue = 1 MaxValue = 8 EMA = 4.344007436833947 TerminalInfoInteger(TERMINAL_PING_LAST) = 42 100本のダニを処理した。サーバーとティック端末の間の到着遅れは、1ミリ秒から8ミリ秒の間で変化する。平均は4ミリ秒強です。これはちょうど、このブランチの始まりであるTP注文のトリガーラグと同じです。 ラグ自体はMT5サーバーの中にある。Server->Terminalのチャンネルは関係ありません。 このラグをなくすよう、開発者に強く要望します。これで、Pingがゼロになると、端末だけでなく、サーバーにも一定の遅延ティックが入力されるようになります。特に、注文は受け付けています。 ZS アービトラージでキッチンブローカーを剥がす人にとって、この内蔵されたラグは天からのマナのようなものです。つまり、ブローカーは相当な追加リスクを負うことになる。 Renat Fatkhullin 2021.01.20 08:56 #38 どのサーバーで確認しましたか？どのようなツールで、どのようなゲートウェイ/データフィードで初期データを形成したのでしょうか？時刻がMT5サーバー自体ではなく、そのリモート側（例：取引所ゲートウェイ）で見積もりプロバイダーによって生成された場合、ギャップが生じる可能性があります。何万、何十万という並列取引による ストレステストなど、どのようなバックグラウンドのプロセスを忘れてしまうのでしょうか。 fxsaber 2021.01.20 09:09 #39 Renat Fatkhullin: На каком сервере проверяли? 多くのサーバーで確認。MQ-Demoを 含む。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム SL/TP注文の受付 fxsaber, 2020.11.25 00:47 MQ-Demoで実行した結果。 Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439 Calculation time = 00:00:11.328, Performance = 38.0 orders/sec. ServerName: MetaQuotes-Demo Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205 Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202 Accepted Length = 357 ms. Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0 Orders (2) before 726444166 with PositionID = 725926764: ------------------------ Checked Orders = 0 ------------------------ このスクリプトは、TPオーダーとその作成のきっかけとなったティックを見つけたと主張しています（テキスト内で色分けされています）。取引サーバー（特にデモ）で価格がオープンポジションのTPレベルに達した場合、対応するTP注文が直ちに作成される（必ずしも執行されない）ように思われるのですが。しかし、この状況では、すぐには起きず、357ミリ秒後に起きたのです どの機器で、どのゲートウェイ/データフィードで初期データが形成されたのか？ FXツール、RannForex-Server、AMTS-gatewayを確認しました。その他の構成については、明確にする必要がある。 時間がMT5サーバー自体ではなく、そのリモート側（例えば、取引所ゲートウェイ）の見積もりプロバイダーによって形成された場合、そのギャップはあり得ます。 MT5サーバーはPingがゼロのマシンに形成されていたと思います。しかし、100％保証のためには明確な説明が必要です。しかし、上記は、あなたのサーバーでも問題があることを示しました。 Renat Fatkhullin 2021.01.20 11:45 #40 fxsaber:TP注文の執行を調査していると、一部のTP注文が、それを受け付けたティックから大きく遅れて作成されていることに気づきました。報告会では、異なるブローカーだけでなく、取引サーバーと同じマシンにあるターミナルで取引を行う場合にも、この状況が繰り返されることがわかりました。I.e.非常に低いpingで、Trading Server用の単一の取引アカウントを使用します。 ぜひ、皆さんのアカウントから結果を共有してください。MT5をより良くするために 58,000件のオーダーをチェックし、300msでオーバーシュートしたケースを1件だけ見つけたという、非常に細かい点を「忘れて」います。この1点（58000分の1）は、このチェックの際に明確に強調されるべきでした。 以前の100万円チェックの時も、一人の異常値を探して正常な動作であるかのように装っていたのと同じです。 サーバーのログを確認したところ、約1500万件の口座と約200万件のオープンポジション があり、その間に近隣の仮想サーバーやハイパーバイザーで何かが起きていたため、MetaQuotes-Demoサーバーとの仮想化がその数秒間（2020.09.30 19:07 4秒間）物理的に病んでいることが分かりました。 いずれにせよ、どのようなシステムにも必ず単一の異常値は存在するが、さらに調べてみることにする。 12345678 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
https://www.mql5.com/ru/forum/341117 は現在も問題になっている
前回、この問題は言及されたブローカーで解決されました。
開発者の皆様、アーキテクチャに関する以下の質問にお答えください。戦闘用のアプリケーションに必要な情報です。ノークレーム。
同じ価格でロットの異なる2つの指値があります。起動トリガーの順番はどうなっているのでしょうか？
この問いには、いくつか答えがあります。
もし私の理解が正しければ、始値を変更した後、そのリミッターはサーバーのすべてのリミッターのリストテーブルに適切に挿入され、始値でソートされることになるのです。そうすると、質問の答えは、同じ価格の注文のリストの最初に埋め込まれているのか、最後に埋め込まれているのか、ということになる。
同じ質問は、制限ではなく、トークンのことです。同一のテイクをトリガーする順番は、何に依存するのでしょうか？IDポジションか何かでしょうか？
これが戦闘にどう役立つかを説明しよう。例えば、同じレベルのリミッター（またはポジションティー）を2つ持っているが、ロットが異なる。リミット（ティー）の実行が最後の修正に依存するのであれば、ロットを上げることでリミッターを修正するだけでFillRateを上げることができますね。
おそらく、対応するMT5サーバー部分の実装を書いた人でないと、この答えはわからないと思います。
ブローカーと連携し、ボトルネックを発見する
同じ価格でロットの異なる2つの指値があります。起動トリガーの順番はどうなっているのでしょうか？
この問いには、いくつか答えがあります。
バリアント4は4作目で使われたような気がします。つまり、何らかの修正があれば、その注文は対応する価格水準の待ち行列の最後尾に移動したのである。
ミツバチ対ハチミツみたいなもんかな？)
この瞬間に、この状況で、お互いに利益があり、それが実現した。
MT5のTP注文は、FillRate（注文のどの部分が満たされたか）を調べることができるのが特徴です。
このような数万件の注文を分析した結果、FillRateはシンボルに非常に大きく依存することがわかりました。TP注文のパックが同時にトリガされた場合、パック内の注文数が増えるにつれてFillRateが減少します。
その他、具体的なニュアンスも明らかになった。しかし、これはすでにブローカーと話し合っている。
FillRateを増やすためのレシピ：同じティックとリミッターを1つの共通のMT5リミッターにまとめる。
しかし、このデータはこの話題のオマケに過ぎない。ブローカーに依存しない問題は、MT5がティックで遅れ、その結果、保留中の注文（SL/TPレベルを含む）の受付で遅れをとっていることです。
そしてリダイレクト後、MT5は次のティックまで毎回待機し、価格がTPレベル（またはリミット）を満たすかどうかをチェックします。最大で数秒かかることもあります。また、チェックは必ずリジェクト（またはパーシャルフィル）の直後に行う必要があります。
OnTickは、ティックがトレードサーバーに書き込まれるより数ミリ秒後にトリガーされます。
結果
100本のダニを処理した。サーバーとティック端末の間の到着遅れは、1ミリ秒から8ミリ秒の間で変化する。平均は4ミリ秒強です。これはちょうど、このブランチの始まりであるTP注文のトリガーラグと同じです。
ラグ自体はMT5サーバーの中にある。Server->Terminalのチャンネルは関係ありません。
このラグをなくすよう、開発者に強く要望します。これで、Pingがゼロになると、端末だけでなく、サーバーにも一定の遅延ティックが入力されるようになります。特に、注文は受け付けています。
ZS アービトラージでキッチンブローカーを剥がす人にとって、この内蔵されたラグは天からのマナのようなものです。つまり、ブローカーは相当な追加リスクを負うことになる。
Renat Fatkhullin:
На каком сервере проверяли?
多くのサーバーで確認。MQ-Demoを 含む。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
SL/TP注文の受付
fxsaber, 2020.11.25 00:47
MQ-Demoで実行した結果。
このスクリプトは、TPオーダーとその作成のきっかけとなったティックを見つけたと主張しています（テキスト内で色分けされています）。取引サーバー（特にデモ）で価格がオープンポジションのTPレベルに達した場合、対応するTP注文が直ちに作成される（必ずしも執行されない）ように思われるのですが。しかし、この状況では、すぐには起きず、357ミリ秒後に起きたのです
どの機器で、どのゲートウェイ/データフィードで初期データが形成されたのか？
FXツール、RannForex-Server、AMTS-gatewayを確認しました。その他の構成については、明確にする必要がある。
MT5サーバーはPingがゼロのマシンに形成されていたと思います。しかし、100％保証のためには明確な説明が必要です。しかし、上記は、あなたのサーバーでも問題があることを示しました。
TP注文の執行を調査していると、一部のTP注文が、それを受け付けたティックから大きく遅れて作成されていることに気づきました。
報告会では、異なるブローカーだけでなく、取引サーバーと同じマシンにあるターミナルで取引を行う場合にも、この状況が繰り返されることがわかりました。I.e.非常に低いpingで、Trading Server用の単一の取引アカウントを使用します。
ぜひ、皆さんのアカウントから結果を共有してください。MT5をより良くするために58,000件のオーダーをチェックし、300msでオーバーシュートしたケースを1件だけ見つけたという、非常に細かい点を「忘れて」います。この1点（58000分の1）は、このチェックの際に明確に強調されるべきでした。
以前の100万円チェックの時も、一人の異常値を探して正常な動作であるかのように装っていたのと同じです。
サーバーのログを確認したところ、約1500万件の口座と約200万件のオープンポジション があり、その間に近隣の仮想サーバーやハイパーバイザーで何かが起きていたため、MetaQuotes-Demoサーバーとの仮想化がその数秒間（2020.09.30 19:07 4秒間）物理的に病んでいることが分かりました。
いずれにせよ、どのようなシステムにも必ず単一の異常値は存在するが、さらに調べてみることにする。