MT5とスピードの関係 - ページ 37 1...303132333435363738394041424344...94 新しいコメント Dmi3 2020.09.29 18:26 #361 prostotrader:VolumeとBidが必要ない場合は、OnTick()が正しい解決策ですが、私は必要です。は、音量だけでなく、スタックの変化にも対応していますが、残念ながらOnTick()は機能しません。 ありがとうございます。もちろん、すべて完璧に理解しています。 私の状況との 主な違いは! OnTick()イベントはOnBook()と違ってキューに蓄積されないことです。 つまり、OnBookからとっくにキューを出ているデータに対して実行するリスクを回避することができます。:) prostotrader 2020.09.29 18:39 #362 Dmi3:ありがとうございます。もちろん、完璧に理解していますよ。私の状況との 主な違いは! OnTick()イベントはOnBook()と違ってキューに蓄積されないことです。つまり、OnBook()からとっくにキューを出ているデータに対して実行するリスクを回避することができます。:) 去年か一昨年、私とAndrey Khatimlianskiiは OnTick()とOnBook()についてテストを行いました。 そして、両者に差がない(あるいはOnBook()がOnTick()に比べて数マイクロ秒遅れて いる)ことが判明しましたが 出来高がなく、OnTick()での変化(ask/bidより高い/低い)の追跡ができない。 fxsaber 2020.09.29 18:39 #363 Dmi3:つまり、OnBookから順番に私のところに来て、とっくにガラスから消えてしまったデータを実行する羽目になるリスクを避けることができるのです。:) OnBookでは、非同期取引注文のみを 使用することが合理的である。でも、たしかにSymbolInfoTickでも遅くなっていますね。だから、何の役にも立たない。 Dmi3 2020.09.29 18:46 #364 prostotrader:そうだ、誰と話していたのか、すっかり忘れていた...。すみません...追加じゃあ、その半分くらいの レベルでやって みたら......。なんだこの荒らしは :))))))失礼ながら、その数字は取引量しか教えてくれません。タックスベースという面白い数字、自分で分かっているんですね。しかし、fxsaberは知らない、本当に、彼はそれを持っていない:) Dmi3 2020.09.29 18:48 #365 prostotrader:去年か一昨年、Andrey Khatimlianskiiと 私はOnTick()とOnBook()のテストを行いました。そして、両者に差がない(あるいはOnBook()がOnTick()に比べて数マイクロ秒遅れて いる)ように見えたが出来高がなく、OnTick()での変化(ask/bidより高い/低い)の追跡ができない。 このスレを読んでいると、また「真空中の球形馬」ですね。私は実務家です。すみません、すべてお金で測りますし、何か決断をすれば、それがそのまま自分の収入額になります。 Dmi3 2020.09.29 18:50 #366 fxsaber:OnBookで使用するのは非同期取引注文のみが 合理的です。しかし、私の場合、SymbolInfoTickでも遅いです。だから、何の役にも立たない。 非同期注文が必要なのは、バスケット取引で、遅い足の後に速い足の「パック」が買われる場合だけです。また、非同期が勝てないケースもあります。 Dmi3 2020.09.29 18:51 #367 fxsaber:OnBookで使用するのは非同期取引注文のみが 合理的です。しかし、私の場合、SymbolInfoTickでも遅いです。したがって、うまくいっていないのです。 SymbolInfoTickは私には遅すぎる。コミュニティ全体の中で、私たちだけが問題を抱えているような気がするんです。他のみんなは元気です :( fxsaber 2020.09.29 19:00 #368 Dmi3:非同期注文が必要となるのは、バスケット取引において、遅い足の後に速い足の「パック」が買われる場合である。また、非同期ではメリットがない場合もあります。 SynchronousOrderSendは 10msで動作します。一度にいくつもある場合もあります。その後、OnBookが50ms実行される。この間、キューが蓄積され、hello relevance!OnBookで非同期が問題になるのは、この文脈だけです。 Dmi3 2020.09.29 19:02 #369 fxsaber:同期的なOrderSendは10msで完了する。一度にいくつもある場合もあります。その後、OnBookが50ms実行される。この間、キューが蓄積され、hello relevance!この文脈ではOnBookの非同期機能だけが問題となる。 1つのEAに1つのロジックがあり、1つのループに複数の注文があることはできないのですが。上に書いたカゴは別として。 fxsaber 2020.09.29 19:03 #370 prostotrader:じゃあ、 あなたの レベルで、その半分を取引してみたら......。 私のレベルでは、その何%にも達しません。さすがです。しかし、それは奇妙な議論です。 1...303132333435363738394041424344...94 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
VolumeとBidが必要ない場合は、OnTick()が正しい解決策ですが、私は必要です。
は、音量だけでなく、スタックの変化にも対応していますが、残念ながらOnTick()は機能しません。
ありがとうございます。もちろん、すべて完璧に理解しています。
私の状況との 主な違いは! OnTick()イベントはOnBook()と違ってキューに蓄積されないことです。
つまり、OnBookからとっくにキューを出ているデータに対して実行するリスクを回避することができます。:)
ありがとうございます。もちろん、完璧に理解していますよ。
私の状況との 主な違いは! OnTick()イベントはOnBook()と違ってキューに蓄積されないことです。
つまり、OnBook()からとっくにキューを出ているデータに対して実行するリスクを回避することができます。:)
去年か一昨年、私とAndrey Khatimlianskiiは OnTick()とOnBook()についてテストを行いました。
そして、両者に差がない(あるいはOnBook()がOnTick()に比べて数マイクロ秒遅れて いる)ことが判明しましたが
出来高がなく、OnTick()での変化(ask/bidより高い/低い)の追跡ができない。
つまり、OnBookから順番に私のところに来て、とっくにガラスから消えてしまったデータを実行する羽目になるリスクを避けることができるのです。:)
OnBookでは、非同期取引注文のみを 使用することが合理的である。でも、たしかにSymbolInfoTickでも遅くなっていますね。だから、何の役にも立たない。
そうだ、誰と話していたのか、すっかり忘れていた...。
すみません...
追加
じゃあ、その半分くらいの レベルでやって みたら......。
なんだこの荒らしは :))))))
失礼ながら、その数字は取引量しか教えてくれません。タックスベースという面白い数字、自分で分かっているんですね。しかし、fxsaberは知らない、本当に、彼はそれを持っていない:)
去年か一昨年、Andrey Khatimlianskiiと 私はOnTick()とOnBook()のテストを行いました。
そして、両者に差がない(あるいはOnBook()がOnTick()に比べて数マイクロ秒遅れて いる)ように見えたが
出来高がなく、OnTick()での変化(ask/bidより高い/低い)の追跡ができない。
このスレを読んでいると、また「真空中の球形馬」ですね。私は実務家です。すみません、すべてお金で測りますし、何か決断をすれば、それがそのまま自分の収入額になります。
OnBookで使用するのは非同期取引注文のみが 合理的です。しかし、私の場合、SymbolInfoTickでも遅いです。だから、何の役にも立たない。
非同期注文が必要なのは、バスケット取引で、遅い足の後に速い足の「パック」が買われる場合だけです。また、非同期が勝てないケースもあります。
OnBookで使用するのは非同期取引注文のみが 合理的です。しかし、私の場合、SymbolInfoTickでも遅いです。したがって、うまくいっていないのです。
SymbolInfoTickは私には遅すぎる。コミュニティ全体の中で、私たちだけが問題を抱えているような気がするんです。他のみんなは元気です :(
非同期注文が必要となるのは、バスケット取引において、遅い足の後に速い足の「パック」が買われる場合である。また、非同期ではメリットがない場合もあります。
SynchronousOrderSendは 10msで動作します。一度にいくつもある場合もあります。その後、OnBookが50ms実行される。この間、キューが蓄積され、hello relevance!OnBookで非同期が問題になるのは、この文脈だけです。
同期的なOrderSendは10msで完了する。一度にいくつもある場合もあります。その後、OnBookが50ms実行される。この間、キューが蓄積され、hello relevance!この文脈ではOnBookの非同期機能だけが問題となる。
1つのEAに1つのロジックがあり、1つのループに複数の注文があることはできないのですが。上に書いたカゴは別として。
じゃあ、 あなたの レベルで、その半分を取引してみたら......。
私のレベルでは、その何%にも達しません。さすがです。しかし、それは奇妙な議論です。