mem_time = GetMicrosecondCount(); - для проверки времени задержки OnTradeTransaction
mem_start_time = TimeCurrent(); - для сужения рамок поиска в истории
В языке MQL5 предусмотрена обработка некоторых предопределенных событий. Функции для обработки этих событий должны быть определены в программе MQL5: имя функции, тип возвращаемого значения, состав параметров (если они есть) и их типы должны строго соответствовать описанию функции-обработчика события. Именно по типу возвращаемого значения и по...
ログの時間を見てください。これはすべて1つのmsで起こったことで、その隣には(同じmsで)たくさんのOnBookがありました。
すべてのイベントをカウンターで数えることができますが、視覚的にもOnBooksが増えていることがわかります。
Async orderを使うって書いてなかったっけ?
気になったのですが、取引の執行を制御するためにどのようなアルゴリズムを使っているのでしょうか?
Andrew: この数字は、OnFunctionsがトリガーされたときの固定マイクロ秒数で、そのときに配列からすべてをまとめてプリントしています。OnBooksの合計はもっと多いかもしれない。数えてみるが、なぜOnTicksより先にキューに飛ばすのか、その理由は不明である。それとも、すべてのOnTickがOnBookに対応するわけではないのですか?
ようこそ、ネットワークの世界へ ))))
一番簡単なのは、管理者権限でNetstat - a -b を実行することです。
ポートやソフトを見ればわかると思いますが、MT5サーバは非同期でパケットを渡し、端末が必要な "棚 "に様々な情報を入れているのだと思います。
SZZY:Print()と、一度にたくさんプリントした場合のプリントのスキップについてですが、ご存知ですか?- ファイルに情報を書き込むだけ - そうすれば、すべてと順番に保存されますが、閉じる前にファイルを閉じることを忘れないでください。理論的には、ファイル内のログでPrint()が完了する必要がありますが、チェックしていないと一般的に私は信頼しない場合、多くのデータを出力します。ここで議論されているhttps://www.mql5.com/ru/forum/329730, 非常によく「ミッシングプリント」が議論されている ))) 。- 探索
アンドリュー、OnFunctionsがトリガーされたときのマイクロ秒を固定し、配列からまとめて出力しています。もしかしたら、OnBookは全部でもっとあるかもしれません。数えてみますが、キューの中でOnTicksより先にスキップされる理由は不明です。それとも、すべてのOnTickがOnBookに対応するわけではないのですか?
了解です。
まあ、とにかくOnBookがいっぱいあるんですよ。そんなログでは結論は出せない。
Async orderを使ってるって書いてなかったっけ?
取引執行を制御するために、どのようなアルゴリズムを使用しているのでしょうか?
OnTradeTransaction() において、長時間サーバーからの応答がない場合のチェック機能を追加。
一般的にはマジックで。
EA設定時に各シンボルに対して65535個のマジックシンボルを予約しています。
そして、オーダーを送る際には、他のシンボルと一切交差しないユニークなマジックナンバーを割り当てます。
他の楽器と一切重複しないものであること。
これは、シンボルの初期マジックナンバーを設定する方法です。
マジック - ulong (8 バイト) 例.
GAZR-3.12
Byte[7](上位バイト)は "G"
Byte[6]は "A"
バイト[5] "Z "用
Byte[4]は "R "です。
Byte[3]は "3 "です。
Byte[2]は "12"
Byte[1]とByte[0]はマジコン予備軍(65535)
注文を出すときは、こうしてマジックを進めています。
しかし、これはシンボル名が標準化されて いるFORTSにのみ有効です!
追加
オーダーの送信に成功した場合
ときをきざむ
そして、(OnTradeTransactionで応答がない場合)。
そして、FindOrderBuyMagic 関数自体も
によって追加されました。
オートマジックの1バイト目にEA識別子(0〜255)を追加するのが "グッドアイディア "です。
が、まだ必要ないので、やってません :)
OnTradeTransaction() において、長時間サーバーからの応答がない場合のチェック機能を追加。
ご指摘ありがとうございます。
1.証券会社の2台目以降の端末は有料で、株だけを取引する戦略(ストックポートフォリオ)は持っていない。
2.蓄積されたGetMicrosecondCount() を出力するのであれば
OnDeinit()でタイマーを使わずに実行すると、EAが終了するときにすべてが表示されます。
ブローカーへのリンクを送ってください、LCで可能です。
これは面白い枝だ...。:-)
ようこそ、ネットワークの世界へ ))))
一番簡単なのは、管理者権限でNetstat - a -b を実行することです。
ポートやソフトを見ればわかると思いますが、MT5サーバは非同期でパケットを渡し、端末が必要な "棚 "に様々な情報を入れているのだと思います。
HH:Print()と、一度にたくさん出力した場合のプリントのスキップについてご存知ですか?- ファイルに情報を書き込むだけです。そうすれば、すべてを順番に保存することができますが、その前にファイルを閉じるのを忘れないでください。理論的には、ファイル内のログでPrint()が完了する必要がありますが、チェックしていないと一般的に私は信頼しない場合、多くのデータを出力します。ここで議論されているhttps://www.mql5.com/ru/forum/329730, 非常によく「ミッシングプリント」が議論されている ))) 。- 探索
イゴール プリントの消失については、ログファイルを開いていない人たちが100回くらい議論していますし、リナット・ファットクリン自身もログファイルでは何も消失していないと書いていますね。しかし、あなたの投稿は無駄ではありませんでした :) 私は別のファイルに出力を追加しました、さらに、私は2つの配列を注文する私の設計の可能なバグを回避するために少し異なる出力(CArrayObjにすべてのイベントを収集)、すなわち、私は二つの配列からCArrayObjにすべてを入れて、マイクロ秒によってソートして何のイベントTickまたはBookをマークして出力した2番目のファイルを作りました。
そうそう、それとポートがどうのこうの、どうのこうのって。EAのイベントキューをテストしているところです。OnBookは常にキューに入れられ、OnTickが既にキューにある場合、OnTickは消えることがあります(マニュアルの通り)。1.OnTicksが「キューに入れずに」2.OnBookのシステム遅延がある場合のみ、OnTickなしで別のOnTickの後の状況は、私がチェックしたいものです、これは、以前に同僚によって識別秒のラグを説明することができます。Total OnBooksは1日で2倍以上になっていますが、なぜ遅れているのでしょうか? この遅れが非同期パケットやパースによるものならそうかもしれませんが、今のところExpert Advisorで到着の事実を確認する程度です。残りのニュアンスを考えてどうテストするか、まだ考えていない。
ここに新しいコードがあります。オープニングで私は仕事の正しさをテストし、一日のために実行されます。
s.w. 理由は、Tickがカップを変えずに同じ価格で通過した場合 - OnBookが形成されていない、とも考えられます。 私は株式取引の専門家ではないので、誰が教えてくれるでしょうか。OnTickは常にOnBookを引き起こすと思って いました。
しかし、担当者はその答えに納得しているのだろうか。
すでにすべての答えを受け取り、自分なりの結論を出しています。
一定期間の取引の価格、実現量などを分析する必要があります。
あと、ストラテジーテスターで アルゴリズムの動作をシミュレートする必要がありますね。
OnTickイベントはこれに完璧に対処しており、実際の取引結果とテスターでのモデリング結果はわずかな誤差で一致しており、私は満足しています。
ストリップの解析をより速く行う必要がある場合は、OnTimerを使用することができます。
また、端末に来た全てのティックをOnBookに入れる必要はありません。これは成行注文の実行の仕様です。
また、端末に入ってくるティックは必ずしもOnBookに入る必要はなく、成行注文の執行に特化したものである。
逆に、OnTickハンドラに来るティック(イベント)はすべて OnBookと同期させる必要があります。
OnTickハンドラには、最良買値の価格変化、最良売値の価格変化、取引(last)の3つのイベントが存在します。
取引なしで買値または売値が変化した場合、これはイベントとなり、OnTickはこれらのイベントを受信します。
そして、OnBookもこれらのイベントをキャッチしなければなりませんが、自分自身のイベント、つまりハンドラです。そうでなければ、ハンドラ間で買値と売値のミスマッチが発生します。
また、OnTickがlastイベントを受信した場合、取引が成立したことを意味します。
取引によってOnTickのイベントが発生するのは、取引後に価格やビッドとアスクの量が市場で変化するためです。
悪循環に陥っているのです。
OnTickでもOnBookと同様に、Best BidとBest Askというイベントがあります。
これらのイベントは、常に両方のハンドラで同期している必要があります。
そして、このイベントはそれ自体で最後に、取引後にOnBookにイベントを発生させます。
したがって、OnTickハンドラに来たイベントは、必ず同期的にOnBookに反映させる必要があります。