MT5とスピードの関係 - ページ 34

[fxsaber]

fxsaber:

週末にストーリーを変更することはできないので、確認しようがないのです。

可能性がある。そのため、週末に問題が発覚したのです。

// Демонстрация лагов HistorySelect при удалении нескольких ордеров.
#property script_show_inputs

input int inAmount = 5; // Количество ордеров

#include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/332/Benchmark.mqh
#define _B2(A) _B(A, 10)

// true - ордер есть в истории, false - иначе.
bool HistorySelectOrder( const ulong Ticket )
{
  return((HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket) ||
         (_B2(HistorySelect(0, INT_MAX)) && (HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket)));
}

void OnStart()
{
  HistorySelect(0, INT_MAX); // Создали исторический кеш.
        
  MqlTradeRequest Request = {0};
  MqlTradeResult Result;
                        
  // Выставляем ордера
  Request.action = TRADE_ACTION_PENDING;
  Request.symbol = _Symbol;
  Request.volume = 0.01;
  Request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK) - 1000 * _Point;
  Request.type = ORDER_TYPE_BUY_LIMIT;
        
  for (int i = 0; i < inAmount; i++)
    if (!OrderSend(Request, Result) || (Result.retcode != TRADE_RETCODE_DONE))
      Print("Good!");
            
  // Удаляем ордера
  Request.action = TRADE_ACTION_REMOVE;

  for (int i = OrdersTotal() - 1; i >= 0; i--)
  {
    Request.order = OrderGetTicket(i);

    if (OrderSend(Request, Result) && (Result.retcode == TRADE_RETCODE_DONE) &&
        !HistorySelectOrder(Request.order)) // Проверяем наличие удаленного ордера в истории.
      Print("OrderSend BUG!");
  }
}

結果

2020.09.27 15:46:11.940 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 39 mсs.
2020.09.27 15:46:11.988 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 253 mсs.
2020.09.27 15:46:12.034 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 190 mсs.
2020.09.27 15:46:12.083 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 218 mсs.
2020.09.27 15:46:12.130 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 250 mсs.

2次を削除した後のラグ（最大で数ミリ秒になることもある）。

[secret]

Renat Fatkhullin:

マイクロ秒のカウントに切り替える。ミリ秒はもはや適切ではありません。

なぜMT5サーバーは100-200ミリ秒で保留中の注文を 実行するのですか？(Aで有名なブローカーで)

[Renat Fatkhullin]

fxsaber:

おそらく。そのため、週末に問題が発覚したのです。

結果

2次を削除した後にラグが発生する（最大で数ミリ秒に達することもある）。

注文を削除すると、選択した履歴のキャッシュが完全に無効になります。

通常モードでは、ヒストリーサンプリングの速度は数十マイクロ秒になった。

[Renat Fatkhullin]

secret:

なぜMT5サーバーは100-200ミリ秒で保留中の注文を 実行するのですか？(Aで有名なブローカーで)

実行するか、受け入れるか？

N個のトレードの詳細（全体像が見えるように、引き裂かれた単一の注文ではなく、Pingを含む）がなければ、議論することはできません。

[fxsaber]

Renat Fatkhullin:

オーダーの削除は、選択したストーリーのキャッシュを完全に無効にします。

最初の削除はうまくいくのですが。2枚目には問題があります。この障害は何に関するものですか？

[fxsaber]

fxsaber:

フォーラムで調べてみますね。テスターの中だけで、Generic access to historyがいかに通常の機構より優れているかを示した記憶があります。

これが今回の ケースである。

[secret]

Renat Fatkhullin:

実行するのか、受け入れるのか。

N個の取引に関する詳細（全体像を見ることができるように、引き裂かれた単一の注文ではなく、Pingを含む）がなければ、我々は議論することはできません。

はい、そうです。

価格が指値注文に1ティック触れて跳ね返され、そのティックが100～200ミリ秒未満であった場合。そして、約30～50％の確率で滑りが発生します。すなわち、注文はティックの価格によって実行される時間がない。

ティックの持続時間はブローカーのティックアーカイブで測定されるため、pingは関係ありません。

また、注文番号に従って動くトレーダーは、その瞬間にはごくわずかなので、サーバーの負荷が高いとは思っていません。

流動性不足によるスリッページも関係ない。短いティックにのみ表示されます。敷地面積も小さいですしね。

ここまでは、ブローカー側からの人為的な約定遅延を想定しています。

複数の案件の統計を取るのは時間がかかる。しかし、質問の答えになるのであれば、可能です。

[Renat Fatkhullin]

secret:

実行する。

価格が指値注文に1ティック触れて跳ね返され、そのティックが100～200ms未満であった場合。そして、約30〜50％の確率でスリッページが発生し、注文が執行されます。すなわち、注文はティックの価格によって実行されるのに十分な時間がない。

ティックの持続時間はブローカーのティックアーカイブで測定されるため、pingは関係ありません。

また、注文番号に従って動くトレーダーは、その瞬間にはごくわずかなので、サーバーの負荷が高いとは思っていません。

流動性不足によるスリッページも関係ない。短いティックにのみ表示されます。敷地面積も小さいですしね。

ここまでは、ブローカー側からの人為的な約定遅延を想定しています。

複数の案件の統計を取るのは時間がかかる。しかし、質問の答えになるのであれば、可能です。

詳しく調べる必要がありますが、FXであれば次のティックでトレードになる可能性が高いです。

ログとティックチャートの表が欲しいのですが。

[fxsaber]

secret:

価格が指値注文に1ティック触れて跳ね返され、そのティックが100～200ms未満であった場合。すると、約30～50％の確率で滑りが発生します。つまり、注文がティックの価格で執行されることはないのです。

MT5は関係ありません。デモ口座では、完璧な実行が可能です。

[fxsaber]

スナップショットのデバッグに疲れました。ようやく完璧になった。アドバイザー1名、何もなし。2 - 完璧です。20 - 災害時：CPUが100％未満です。HistorySelectは 何ミリ秒もの遅れがある。

MT5は、多くのExpert Advisorを同時に動作させることを想定していないようです。