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

新しいコメント
 
fxsaber:

どちらの端末がより多くのCPUを消費していると思いますか？

2とその理由

 
fxsaber:

CPUを減らすには、ターミナルのすべてのサブウィンドウ（Market Watch、Navigator、Toolsなど）を閉じ、すべてのチャートを最小化し、ターミナル自体を最小化することをお勧めします。

マーケットウォッチから未使用のシンボルをすべて削除する。特にVPSの場合は重要です。


どうにかして、これらの動作を自動化することをお勧めします。VPSを離れる前に、押して離れる。来てみると......プレス、全部見てるんですね。

私は長い間、algotradersはこのようなチューニングのない、別のバージョンのターミナルが必要だと言ってきました。

上記全てに加え、EAごとに新しいものを追加しています。

ChartSetInteger(0,CHART_SHOW,false);

まだラグがある :(

 
A100:

2ndとその理由。

はい、2枚目です。

 
SymbolInfoTickは どのようなアーキテクチャになっているのですか？なぜ数十ミリ秒単位で実行できるのか、その理由はわかっていない。
 

b2560は、b2592と比較すると、性能面で非常に損をしています。バグの 修正を楽しみにしています。

このスレッドは有用であることがわかった。

 
fxsaber:

b2560は、b2592と比較すると、性能面で非常に損をしています。バグ フィックスを待っている。

b2593 は修正されました。ありがとうございました。

 
注文/取引を取引履歴に追加すると、HistorySelectキャッシュの部分的な再構築ではなく、完全な再構築が行われます。そのため、注文のトリガーに遅れが生じています。 
// Демонстрация полного (не частичного) пересбора HistorySelect-кеша.
#include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/321/Benchmark.mqh

input int inAlertTime = 1; // Нижний порог в миллисекундах

#define _B2(A) _B(A, inAlertTime)

const bool Init = EventSetTimer(1);

void OnTimer()
{
  static MqlTradeRequest Request = {0};
  static MqlTradeResult Result = {0};

  if (PositionSelectByTicket(Result.order)) // Если позиция открыта - закрываем.
  {
    Request.type = ORDER_TYPE_SELL;
    Request.price = SymbolInfoDouble(_Symbol, SYMBOL_BID);
    Request.position = Result.order;
  }
  else // Иначе - открываем.
  {
    Request.action = TRADE_ACTION_DEAL;
    Request.type = ORDER_TYPE_BUY;
    Request.symbol = _Symbol;
    Request.volume = 0.1;
    Request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
    Request.position = 0;
  }

  if (OrderSend(Request, Result))
    _B2(HistorySelect(0, INT_MAX));
}

結果 
2020.09.08 20:23:32.103 Alert: Time[Test6.mq5 411: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:23:32.239 Alert: Time[Test6.mq5 411: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:31:59.863 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 9 ms.
2020.09.08 20:32:00.845 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:32:01.856 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 4 ms.
2020.09.08 20:32:02.846 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 7 ms.


なぜ、それが重要なのか。HFTロボットが動いているとしよう。同じ口座で、手作業で取引を行う。以上で、HFT-ロボットがHistorySelect-cacheを適切な結果で削除しました。もちろん、HFT-Robotの歴史は1万件の注文・取引ではなく、それ以上のものです。このような履歴のために、キャッシュをすべて作り直すのはコストがかかる。だからこそ、追加するのが理にかなっているのです。


手動取引でロボットの速度が低下してはいけないことは明らかです。純粋なアルゴリズム取引の場合、問題は注文がトリガーされたときに発生します。

 

現在の取引環境（ポジションと注文）の完全な（構造体の）スナップショットを作成できる機能が非常に不足しています。

Position*関数とOrder*関数による変形は、ループ内でこれら2つのリストを渡すときに衝突（活発な取引）を引き起こします。何かが失われた、または説明されていない。

インスタント・フル・スナップショットなら、これらの問題を回避することができます。


ZZY Market Watch用のフルスナップショット - まだ関連性を評価していない。MT5をHFT(LCI)に近づける。

 

CPUが100％で、OrderSendの待ち時間が1秒以上という状態に、Terminal（とnone）を管理（わざとではありません）。

おそらく、原因を見つけるのは簡単ではないでしょう。


ZZY そのようなブレーキは、似たような設計が原因だと思われます。

void OnTrade()
{
  OnTick();
}

再現するためのコードを作成できていません。


事実、Ping50msで数秒後に売買注文が 成立する状態（Terminal log）に追い込むことが可能です。EAを削除すると、100ms以内に売買注文が執行されるようになります。

 
fxsaber:

現在の取引環境（ポジションと注文）の完全な（構造体の）スナップショットを作成できる機能が非常に不足しています。

Position*関数とOrder*関数による変形は、ループ内でこれら2つのリストを渡すときに衝突（活発な取引）を引き起こします。何かが失われた、または説明されていない。

インスタント・フル・スナップショットなら、これらの問題を回避することができます。


ZZY Market Watch用のフルスナップショット - まだ関連性を評価していない。MT5をHFT(LCHI)に近づける。

そして、チケットごとのオーダー-トランザクション-ポジションを追跡し、チケットのポジションからさかのぼってオーダー内容や取引条件を把握する機能をフル稼働させました。履歴ステータスによる追跡は邪道な現実。

フルクリック環境はかっこいいけど、高いし、あまり必要ないらしい。 市場が崩壊しているのに)))

自分としては、オーダーと割り切っています。注文を実行 するための注文は、保留中の注文である。成行注文は紛らわしい。

専門家以外の意見で厳しく判断しないこと。

1...202122232425262728293031323334...94
新しいコメント