フォルツァ執行上の問題点 - ページ 4 1234567891011...156 新しいコメント Renat Fatkhullin 2014.12.24 15:43 #31 Mikalas: では、TM-5のレイテンシー（内部ネットワーク内）は30ms程度が普通だとお考えですか？なぜ社内用と考えるのか？1)OnTradeTransactionで、リクエストについて受け取った中間ステータスの数を確認します。各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。10倍はありそうな気がします。水面上に突き出たアスベルグの破片を見て、騙されることはない。2倍ではなく、あくまで1倍ということです。これはあくまで低ベースでの効果です。いずれにせよ、私たちは作業を続け、さらに良い結果を得るつもりです。 Mikhail Filimonov 2014.12.24 15:47 #32 Renat:なぜ社内用と考えるのか？1) OnTradeTransactionで、注文に関する中間ステータスをいくつ受け取ったか確認します。各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。いずれにせよ、私たちは作業を続け、さらに良い結果を得るつもりです。そう、仮想マシン（ローカルネットワーク）からのレイテンシは、自宅（インターネット）から取引するときのレイテンシと同等（それ以上）だからです。レナート、この深刻な問題をぜひ解決してほしい。私たち（ユーザー）には、あまり長く待たずに、幸運を心から願っています。P/S 質問に答えていただき、ありがとうございました。そして、こんなに早くスピードアップしていただき、本当にありがとうございます。 Mikhail Filimonov 2014.12.25 08:49 #33 papaklass:為替なぜサーバーでこのような遅延が発生するのでしょうか？True build 1010です。 104msと146msのことですか？ Alexey Klenov 2014.12.25 09:56 #34 Mikalas: 104msと146msのことでしょうか？24msから146msの間である可能性が高い ほぼ同時刻にターミナルを出発していたのに Mikhail Filimonov 2014.12.25 10:58 #35 olyakish:24msから146msの間と思われる が、ほぼ同時にターミナルを出発していた。この「浮遊」バグについては、「発注時のFORTS大遅延」というスレッドで取り上げました。( https://www.mql5.com/ru/forum/19681 ) これは残念ながら1035ビルドでは修正されていません。このスレッドでレナートはこう言っている。"時折発生するターミナルへのフローティングレスポンスの納期はまだケアできていないので、引き続き取り組んでいく。"また「いずれにせよ、我々は作業を続けており、さらに良い結果を得ることができるだろう。" Alexey Klenov 2014.12.25 20:53 #36 papaklass:24と146、30と104の違いである。しかし、すべての注文が実行されるまでの時間が 大幅に増加することもあります。その時、トレードの行方は。私は、このことをかなり綿密に検討し、今、必要な結論に達しました。 ブローカーにより近い専用サーバー（仮想ではなく、専用のもの）良質なデータセンター内のサーバー メディアリソースを持たない100Mbpsでも信頼性の高いネットワーク（インターネットに接続しないクロスコネクトが理想的です）ブローカーへのPingはできるだけ安定し、ディップがないこと 最大偏差（最小と最大の差）1msサーバー上の端末の総数が、取引のピーク時の負荷（Expert Advisorの）の25～30％を超えないこと。風ならサーバー2012（多くの人が主張するように、ネットワークでより安定的に動作します）この後、いくつかのテストを行うことができます ... Alexey Klenov 2014.12.25 22:50 #37 papaklass: サーバーは仮想、Windows - Server 2012 R、ギガビットネットワーク、ping 7msです。ネットワークはかなり安定しています。仮想マシンの負荷は、MTサーバーでの注文処理ではなく、端末からの一括注文送信に影響します（タイミングに差が生じます）。サーバーのIPを教えてくれれば、自分で調べてみるよ。mt5が注文を出すと、仮想マシンが その情報を物理マシンに送り、物理マシンがそれをネットワーク・インターフェースに送ります。最初のフェーズは、ログに次のように書かれています。2014.12.23 10:44:28.630 Trades '880758': market buy 0.03 EURUSD.e(でしょう）+ この時点で、サーバーにpingを打つことをお勧めします -t+ また、MT5サーバはPLとのパイプとして機能し、MT5サーバとPLとの接続から、PLとPLとの注文への反応がトータル時間を増加させる可能性がある。究極のインスタンスとしてМТ5サーバが必要です（マーケットメーカーのようなブローカー）。 Alexey Klenov 2014.12.26 07:04 #38 サーバーにPingが打たれず、検索に引っかからない。 Alexey Klenov 2014.12.26 08:40 #39 papaklass:netstatコマンドで変なIPが出る。ヨーロッパNo.1サーバーのIPを特定できないの方が簡単かもしれませんね。 アカウントファイルを開き、そこからサーバー名/ブローカー名の入った画像を表示します。 Alexey Klenov 2014.12.26 09:38 #40 最後の画面で止まったままです・・・。 1234567891011...156 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
では、TM-5のレイテンシー（内部ネットワーク内）は30ms程度が普通だとお考えですか？
なぜ社内用と考えるのか？
1)OnTradeTransactionで、リクエストについて受け取った中間ステータスの数を確認します。
各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。
現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。
2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。
10倍はありそうな気がします。
水面上に突き出たアスベルグの破片を見て、騙されることはない。
2倍ではなく、あくまで1倍ということです。これはあくまで低ベースでの効果です。
いずれにせよ、私たちは作業を続け、さらに良い結果を得るつもりです。
なぜ社内用と考えるのか？
1) OnTradeTransactionで、注文に関する中間ステータスをいくつ受け取ったか確認します。
各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。
現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。
2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。
いずれにせよ、私たちは作業を続け、さらに良い結果を得るつもりです。
そう、仮想マシン（ローカルネットワーク）からのレイテンシは、自宅（インターネット）から取引するときのレイテンシと同等（それ以上）だからです。
レナート、この深刻な問題をぜひ解決してほしい。
私たち（ユーザー）には、あまり長く待たずに、幸運を心から願っています。
P/S 質問に答えていただき、ありがとうございました。
そして、こんなに早くスピードアップしていただき、本当にありがとうございます。
為替なぜサーバーでこのような遅延が発生するのでしょうか？True build 1010です。
104msと146msのことでしょうか？
24msから146msの間である可能性が高い
ほぼ同時刻にターミナルを出発していたのに
24msから146msの間と思われる
が、ほぼ同時にターミナルを出発していた。
この「浮遊」バグについては、「発注時のFORTS大遅延」というスレッドで取り上げました。
( https://www.mql5.com/ru/forum/19681 ) これは残念ながら1035ビルドでは修正されていません。
このスレッドでレナートはこう言っている。
"時折発生するターミナルへのフローティングレスポンスの納期はまだケアできていないので、引き続き取り組んでいく。"
また
「いずれにせよ、我々は作業を続けており、さらに良い結果を得ることができるだろう。"
24と146、30と104の違いである。
しかし、すべての注文が実行されるまでの時間が 大幅に増加することもあります。
その時、トレードの行方は。
私は、このことをかなり綿密に検討し、今、必要な結論に達しました。
この後、いくつかのテストを行うことができます ...
サーバーは仮想、Windows - Server 2012 R、ギガビットネットワーク、ping 7msです。ネットワークはかなり安定しています。
仮想マシンの負荷は、MTサーバーでの注文処理ではなく、端末からの一括注文送信に影響します（タイミングに差が生じます）。
サーバーのIPを教えてくれれば、自分で調べてみるよ。
mt5が注文を出すと、仮想マシンが その情報を物理マシンに送り、物理マシンがそれをネットワーク・インターフェースに送ります。
最初のフェーズは、ログに次のように書かれています。
(でしょう）
+ この時点で、サーバーにpingを打つことをお勧めします -t
+ また、MT5サーバはPLとのパイプとして機能し、MT5サーバとPLとの接続から、PLとPLとの注文への反応がトータル時間を増加させる可能性がある。
究極のインスタンスとしてМТ5サーバが必要です（マーケットメーカーのようなブローカー）。
netstatコマンドで変なIPが出る。
ヨーロッパNo.1サーバーのIPを特定できない
の方が簡単かもしれませんね。
アカウントファイルを開き、そこからサーバー名/ブローカー名の入った画像を表示します。
最後の画面で止まったままです・・・。