フォルツァ執行上の問題点 - ページ 79 1...727374757677787980818283848586...156 新しいコメント Renat Fatkhullin 2016.10.10 19:10 #781 トレーディングで 低遅延処理を行う際の一般的な考え方。1ラウンド10ミリ秒以下になると、レイテンシーの安定 性はほとんど保証 されません。目の前にたくさんのネットワークがある場合、遅延の安定性は保証ではなく、贈り物であるピアネットワークの帯域幅やレイテンシーを制御することはできません。保証を得るためには、ネットワークからすべての仲介者を排除する必要があります。を保証するためには、ハードウェア（帯域、コンピュータ、ルータ）に投資し、最大経路を制御する必要があります。オタクで完璧主義者でなければならない。 テクノギークである証券会社やシステムは、明らかに技術インフラに取り組み、その改善に投資しています。でも、みんながみんな、そうしているわけではないんです、残念ながら。 prostotrader 2016.10.10 19:10 #782 Renat Fatkhullin:リモート側の各実行ステップの正確な時刻ではなく、自分の端末で信号を登録/受信したローカル時刻を表示します。この場合、すべての応答（MT5サーバーからの確認と取引所への発注確認の両方）を同時に受信したことになります 029。両者の間には多くのネットワークが存在するため、どのパケットも最短のPing時間で即座に届くという保証はない。ネットワークでの小さな詰まりやネットワーク帯域の不足（ブローカーなど）により、パケットは蓄積され、その後一括して配信されることになります。そのため、ネットワークに問題がある場合、各ステージの時間をカウントすることができません。ブローカーのサーバーに近い理想的なネットワークでは、やはり最小遅延の何らかの保証に頼って、中間ステップの時間をカウントすることができます。 私は完璧なネットワークを持っているので、文句を言うことはできません」という回答は適切ではありません。なぜなら、通常の条件下では人間の知覚を超えた、まったく異なるタイミングの話をしているからです。すなわち、このように。2016.10.10 10:00:05.148 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 2016.10.10 10:00:05.148 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 2016.10.10 10:00:05.154 Trades 'xxxxx': accepted buy limit 5.00 RTS-3.17 at 98850 2016.10.10 10:00:05.154 Trades 'xxxxx': accepted sell limit 5.00 RTS-3.17 at 99780 2016.10.10 10:00:05.155 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in 6.904 ms 2016.10.10 10:00:05.156 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in 7.850 msといった簡単なログを作ってみてはいかがでしょうか。トレードサーバーが注文を受けた -トレードサーバーの時間トレードサーバーが取引所に注文を出した - トレードサーバーの時間取引サーバーが取引所から応答を受け取った-取引サーバーの時刻。そうすれば、この長く続いた話題は一旦終了したはずです。追加されました。そして、これらの回（3回とも）を受け入れて 実行のために配置 するのではなく、送信します。 Renat Fatkhullin 2016.10.10 19:17 #783 もしかしたら、将来的にそうなるかもしれません。 fxsaber 2016.10.10 19:42 #784 Renat Fatkhullin:トレーディングで 低遅延処理を行う際の一般的な考え方。 数百、数千ミリ秒単位で質問しているようです。 Renat Fatkhullin 2016.10.10 20:05 #785 fxsaber: 何百、何千ミリ秒という単位で質問されているようでした。実際には、優れたインフラを構築し、慎重に組み立てられた流動性プロベーダーで1ラウンドあたり3～4ミリ秒の執行を楽しんでいる成熟したブローカーとして、本番稼働後に700～1500ミリ秒の定期的なスパイクを目にすると、人々は唖然とする。そして、完璧なシステムを構築した者は、それと共存し、調整しなければならないのです。つまりこれが現実で、最低遅延の安定性は保証されていないのです。 特に中間ステージが多い環境では。 fxsaber 2016.10.10 20:08 #786 Renat Fatkhullin: 確認しますか？ トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム フォルツァ実行に関する質問 fxsaber さん 2016.10.10 11:38 ここで、開発者がブレーキを再現するための素晴らしい機能を紹介しますこれで「ブレーキが見えない」ということはなくなるでしょう。開発者は、セッション開始時にリクエストの制限をかけ、実行時間を 監視するようにしましょう。遅いと感じたら、ローカルで対応する。現時点では、残念ながら落ち込んでいる状況です。 インフラについてオープンマーケットの最初の数分間のログを掲載することによって？ prostotrader 2016.10.10 20:16 #787 Renat Fatkhullin:実際には、良いインフラを構築し、慎重に組み立てられた流動性プロベーダーで1ラウンドあたり3-4msの約定を楽しんでいる、成熟したブローカーとして、本番稼働後に700-1500msの周期的スパイクを見た人々は床に正座して呆然としています。そして、完璧なシステムを構築した者は、それと共存し、調整しなければならないのです。つまりこれが現実で、最低遅延の安定性は保証されていないのです。 特に中間ステージが多い環境では。レナートには申し訳ないが、これがネットワーク遅延に なることはありえない。2016.09.21 03:31:10.568 Terminal Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'') 2016.09.21 17:30:00.156 Trades 'xxxxx': modify order #44620664 buy limit 5.00 ROSN-3.17 at 36438 sl: 0 tp: 0 -> 36470, sl: 0 tp: 0 placed for execution in 19.086 ms 2016.09.21 17:30:00.157 Trades 'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in 19.185 ms 2016.09.21 17:30:00.160 Trades 'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667) 2016.09.21 17:30:01.064 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market 2016.09.21 17:30:02.004 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 2016.09.21 17:30:04.827 Trades 'xxxxx': accepted exchange sell 5.00 BR-11.16 at market 2016.09.21 17:30:04.827 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in 3764.451 ms 2016.09.21 17:30:04.829 Trades 'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682) 2016.09.21 17:30:05.799 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 2016.09.21 17:30:07.929 Trades 'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 2016.09.21 17:30:07.929 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in 5926.927 ms 2016.09.21 17:30:08.738 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 2016.09.21 17:30:08.775 Trades 'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 2016.09.21 17:30:08.776 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in 2977.588 ms 2016.09.21 17:30:09.585 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 2016.09.21 17:30:09.590 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 placed for execution in 852.561 ms 2016.09.21 17:30:09.597 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 2016.09.21 17:30:09.637 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 2016.09.21 17:30:09.638 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 placed for execution in 40.658 ms 2016.09.21 17:30:10.053 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 2016.09.21 17:30:10.075 Trades 'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 2016.09.21 17:30:10.079 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in 25.974 ms 2016.09.21 17:30:44.537 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 2016.09.21 17:30:44.669 Trades 'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.04 2016.09.21 17:30:44.669 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in 132.352 ms 2016.09.21 17:30:45.165 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 2016.09.21 17:30:45.179 Trades 'xxxxx': accepted sell limit 10.00 Si-6.17 at 70449 2016.09.21 17:30:45.180 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in 14.720 ms Renat Fatkhullin 2016.10.10 20:19 #788 fxsaber: 確認することはできないのでしょうか？ あなたのインフラに。オープンマーケットの最初の数分間のログを掲載することによって？事実上、何もコントロールできないのに、何を確認する必要があるのでしょう。すでに市場公開時には、ノルマを証明するテストを披露しています。しかし、あることがきっかけで、別のことをするようになったということらしい。すでに上記で何度か申し上げましたが、レイテンシーの安定性は保証されていません。もし私たちがブローカーだったら、別の問題で、最も効率的なインフラをケチらずに、最大数のルートを最適化するでしょうね。 Renat Fatkhullin 2016.10.10 20:20 #789 prostotrader:レナートさんには申し訳ないですが、ネットワーク遅延の 可能性はゼロではありません。ネットワークの遅延だけを 考慮している。うまくいってますね。そして、あなたから2、3ホップ離れたところでは、すべてがうまくいっているのです。問題は別のところにある。上記をすべてお読みください。そして、行間を読むことでしょうか。 fxsaber 2016.10.10 20:27 #790 prostotrader:レナートさんには申し訳ないですが、ネットワーク遅延の 可能性はゼロではありません。 くそ、他のプラットフォームでもこのような数秒の注文送信の無意味なことが起こるのか、誰か教えてくれませんか？ 1...727374757677787980818283848586...156 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
トレーディングで 低遅延処理を行う際の一般的な考え方。
テクノギークである証券会社やシステムは、明らかに技術インフラに取り組み、その改善に投資しています。でも、みんながみんな、そうしているわけではないんです、残念ながら。
リモート側の各実行ステップの正確な時刻ではなく、自分の端末で信号を登録/受信したローカル時刻を表示します。
この場合、すべての応答（MT5サーバーからの確認と取引所への発注確認の両方）を同時に受信したことになります 029。両者の間には多くのネットワークが存在するため、どのパケットも最短のPing時間で即座に届くという保証はない。ネットワークでの小さな詰まりやネットワーク帯域の不足（ブローカーなど）により、パケットは蓄積され、その後一括して配信されることになります。
そのため、ネットワークに問題がある場合、各ステージの時間をカウントすることができません。ブローカーのサーバーに近い理想的なネットワークでは、やはり最小遅延の何らかの保証に頼って、中間ステップの時間をカウントすることができます。
私は完璧なネットワークを持っているので、文句を言うことはできません」という回答は適切ではありません。なぜなら、通常の条件下では人間の知覚を超えた、まったく異なるタイミングの話をしているからです。
すなわち、このように。
といった簡単なログを作ってみてはいかがでしょうか。
トレードサーバーが注文を受けた -トレードサーバーの時間
トレードサーバーが取引所に注文を出した - トレードサーバーの時間
取引サーバーが取引所から応答を受け取った-取引サーバーの時刻。
そうすれば、この長く続いた話題は一旦終了したはずです。
追加されました。
そして、これらの回（3回とも）を受け入れて 実行のために配置 するのではなく、送信します。
トレーディングで 低遅延処理を行う際の一般的な考え方。
何百、何千ミリ秒という単位で質問されているようでした。
実際には、優れたインフラを構築し、慎重に組み立てられた流動性プロベーダーで1ラウンドあたり3～4ミリ秒の執行を楽しんでいる成熟したブローカーとして、本番稼働後に700～1500ミリ秒の定期的なスパイクを目にすると、人々は唖然とする。そして、完璧なシステムを構築した者は、それと共存し、調整しなければならないのです。
つまりこれが現実で、最低遅延の安定性は保証されていないのです。
特に中間ステージが多い環境では。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
フォルツァ実行に関する質問
fxsaber さん 2016.10.10 11:38
ここで、開発者がブレーキを再現するための素晴らしい機能を紹介します
これで「ブレーキが見えない」ということはなくなるでしょう。
開発者は、セッション開始時にリクエストの制限をかけ、実行時間を 監視するようにしましょう。遅いと感じたら、ローカルで対応する。
現時点では、残念ながら落ち込んでいる状況です。
実際には、良いインフラを構築し、慎重に組み立てられた流動性プロベーダーで1ラウンドあたり3-4msの約定を楽しんでいる、成熟したブローカーとして、本番稼働後に700-1500msの周期的スパイクを見た人々は床に正座して呆然としています。そして、完璧なシステムを構築した者は、それと共存し、調整しなければならないのです。
つまりこれが現実で、最低遅延の安定性は保証されていないのです。
特に中間ステージが多い環境では。
レナートには申し訳ないが、これがネットワーク遅延に なることはありえない。
確認することはできないのでしょうか？ あなたのインフラに。オープンマーケットの最初の数分間のログを掲載することによって？
事実上、何もコントロールできないのに、何を確認する必要があるのでしょう。
すでに市場公開時には、ノルマを証明するテストを披露しています。しかし、あることがきっかけで、別のことをするようになったということらしい。
すでに上記で何度か申し上げましたが、レイテンシーの安定性は保証されていません。
もし私たちがブローカーだったら、別の問題で、最も効率的なインフラをケチらずに、最大数のルートを最適化するでしょうね。
レナートさんには申し訳ないですが、ネットワーク遅延の 可能性はゼロではありません。
ネットワークの遅延だけを 考慮している。うまくいってますね。そして、あなたから2、3ホップ離れたところでは、すべてがうまくいっているのです。
問題は別のところにある。上記をすべてお読みください。そして、行間を読むことでしょうか。
レナートさんには申し訳ないですが、ネットワーク遅延の 可能性はゼロではありません。