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

新しいコメント
 
fxsaber:

何もわかっていない。リターンをするときは、生成されたキューのOn関数に入ることになる。これは、最初のOrderSendが正しい2番目のOrderSendを送信するのを妨げる一時停止を引き起こすかもしれない。

ポーズ/ディレイは何ですか？3構造のコピーでは？

OnTradeTransaction( параметры )
{
        поместить параметры в очередь
        OnMain();
}

return後のOn関数をすべて保存して、最初のOrderSendが終了したというOn関数を待ち、キューを蓄積 することを提案されていますね。そして、2回目のOrderSendだけを送信する。

すべてのイベントを蓄積する必要はありません。次のイベントのコピーを待たずに、リターン前にイベントを処理し、そのための前提条件が揃い次第、2回目のOrderSendを送信することができる

また、テイクポジションは最初のOrderSendの間に実行できますが、そのOnTradeTransactionは最初のOrderSendからの最終OnTradeTransactionより後に（同じマイクロ秒内ですが）キューに 入ることに気づいていません。

また、そのような時にどのように役立つのでしょうか？

bool HandleNextEvent(ENUM_EVENT_TYPE);

ここでも、あそこでも、最後となる

 
fxsaber:

何もわかっていない。リターンをするときは、生成されたキューのOn関数に入ることになる。これは、最初のOrderSendの直後に正しい2番目のOrderSendを送信することを妨げる一時停止を引き起こすかもしれない。

return後のOn-functionをすべて保存し、最初のOrderSendの終了メッセージがあるOn-functionを待つことで、キューを蓄積することを提案されています。そして、2回目のOrderSendだけを送信する。

同時に、テイクポジションは最初のOrderSendの間に実行できますが、そのOnTradeTransactionは最初のOrderSendから終了したOnTradeTransactionより後に（同じマイクロ秒内に、しかし後に）キューに入ることを理解していません。

キューはありません。新しいイベントは現在のイベントの後に処理され、この期間に発生したすべてのイベントは無視されます。

 
キュー（スタック）は自分で形成するもので、MQはこれを行いません。
 

私見では、注文を「申し込む」ことができれば解決するのではないかと思います。つまり、注文に対する取引が発生したときに、端末がイベントを発生させることである。

しかし、これは私たちではなく、開発者が実装すべきものです。すべての解決策は、いずれにせよ、取引の歴史に 立ち戻ることになるのです。そんなマイクロセコンド的な危機感はないのですが、本当に

しかし、取引が成立したかどうか、レベルがトリガーされたかどうか、誰かがターミナルでポジションを修正したかどうかを調べるために複雑なバイクを書くのは本当に迷惑なことです。

ポジションの取引に関するイベントなど、簡単なことのように見えますが、すべてがずっと簡単になるはずです。

 
Maksim Emeliashin:

しかし、これを実装するのは開発者であり、私たちではありません。

開発者は道具を提供するだけでいい。MQLは基本的に低レベルのプログラミング言語です（C++と同じです）。タスクではなく、計算で使うんですね。そして、高度な判断はすべて自分で行うのです。ツールはあっても、既成のソリューションがない。

 
A100:

pausedelayは何ですか？3つの構造をコピーして？

多様なイベントのキューを処理する際に

そんな時、どのように役立つのでしょうか？

ここぞとばかりに、最後の1枚になるのでしょう。

テイクのクローズを意識してみる。

 
Алексей Тарабанов:

キューはありません。新しいイベントは現在のイベントの後に処理され、この期間に発生したすべてのイベントは無視されます。

無能。

 
fxsaber:

処理すべきキューには様々なイベントがある。

ティーグラウンドでのクローズを意識する。

私は本当に（HandleNextEventを 使ったコードなしで） 初歩的なことを理解していないという事実で止めましょう。

最後になりますが、提案されたHandleNextEventと 私が書いたものの違いは、再帰を経由していることと、私がループを経由していることです。その上、キューは最初に形成され、それを管理することができます...いくつかのイベントを一度に処理したり、他の時間に延期したり、あなたは完全に自由を持っています。

 
このEAがアラートを出さない理由は何ですか？ 
const MqlTick GetMarketWatchTick( void )
{
  MqlTick Tick = {0};
  
  ::SymbolInfoTick(_Symbol, Tick);
  
  return(Tick);
}

const MqlTick GetLastHistoryTick()
{
  MqlTick Tick[1];
  
  ::CopyTicks(_Symbol, Tick, COPY_TICKS_ALL, 0, 1);
  
  return(Tick[0]);
}

void OnTick()
{
  if (GetMarketWatchTick().time_msc > GetLastHistoryTick().time_msc) // Тик из Обзора рынка свежее, чем последний тик из истории.
    Alert("Hello!");
}


同時に、同じチェックで、同じTerminalのコンバットトレーディングアドバイザーに縫い込まれ、Alert.その理由は何でしょうか？

 

2474.

        Last tick time. Selected orders: 0; max time: 0.187 ms; avr time: 0.022 ms; 100000 iterations
        Last 3 days. Selected orders: 1956; max time: 1.832 ms; avr time: 0.301 ms; 100000 iterations
        Orders total: 56561

とても良くなっています。変更した場合 - ありがとうございました。戦闘モードでの性能に注目したい。


PS 戦闘モードでは、取引時にほとんどラグが発生します（5ミリ秒より大きいケースしか出力されません）。

2020.06.03 13:57:27.895 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 14 ms.
2020.06.03 13:57:47.780 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 5 ms.
2020.06.03 14:03:49.844 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 9 ms.
2020.06.03 14:03:51.063 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 8 ms.
2020.06.03 14:03:55.115 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 12 ms.
2020.06.03 14:03:56.935 Alert: Time[NewTicks.mqh 112: ::HistorySelect(TimeMsc/1000,INT_MAX)] = 6 ms.

それ以外は2470よりずっと良いようです。

1234567891011121314...94
新しいコメント