フォルツァ執行上の問題点 - ページ 5 123456789101112...156 新しいコメント kond777 2014.12.26 10:47 #41 パパクラス さん、オリャーキッシュ さん !の存在をRenatが確認した後、なぜこの重要なトピックで個人的なやりとりを始めたのか、その理由は定かではありません。"端末への返信速度 "に浮遊する誤差。 また、MQによって注文執行のトラフィックを全体的に改善することを約束した。それにしても、FXのキッチンで何をどう確認するんだ？ Mikhail Filimonov 2014.12.26 11:53 #42 papaklass:実際、多くの有益な情報を掲載しています。- サーバーの構成- ネットワークチェック方法(ping -t)。-olyakish さんが、仮想サーバーの選択に関する作品を掲載しました。でも、必要なさそうですね。FXには、検証可能なものがたくさんあります。そして、取引所での操作はないと思っているのであれば、共感します。:) Mikhail Filimonov 2014.12.26 11:55 #43 kond777:パパクラス さん、オリャーキッシュ さん !の存在をRenatが確認した後、なぜこの重要なトピックで個人的なやりとりを始めたのか、その理由は定かではありません。"端末への返信速度 "に浮遊する誤差。 また、MQによって注文執行のトラフィックを全体的に改善することを約束した。それにしても、FXのキッチンで何をどう確認するんだ？ Alexey Klenov 2014.12.26 12:36 #44 RE 0 15:30:57.591 Trades '871788': market buy 0.03 EURUSD.e JM 0 15:30:57.591 Trades '871788': market buy 0.04 USDJPY.e EK 0 15:30:57.591 Trades '871788': market sell 0.03 EURJPY.e JS 0 15:30:57.607 Trades '871788': order #23947599 buy 0.03 / 0.03 EURUSD.e at 1.21874 done in 28 ms CS 0 15:30:57.607 Trades '871788': deal #16364222 buy 0.03 EURUSD.e at 1.21874 done (based on order #23947599) KL 0 15:30:57.622 Trades '871788': order #23947600 buy 0.04 / 0.04 USDJPY.e at 120.314 done in 44 ms NF 0 15:30:57.622 Trades '871788': deal #16364223 buy 0.04 USDJPY.e at 120.314 done (based on order #23947600) GF 0 15:30:57.653 Trades '871788': order #23947601 sell 0.03 / 0.03 EURJPY.e at 146.615 done in 74 ms EF 0 15:30:57.653 Trades '871788': deal #16364224 sell 0.03 EURJPY.e at 146.615 done (based on order #23947601) NM 0 15:31:56.771 Trades '871788': market buy 0.03 EURUSD.e FD 0 15:31:56.771 Trades '871788': market buy 0.04 USDJPY.e IS 0 15:31:56.771 Trades '871788': market sell 0.03 EURJPY.e LK 0 15:31:56.803 Trades '871788': order #23947606 buy 0.03 / 0.03 EURUSD.e at 1.21877 done in 33 ms RJ 0 15:31:56.803 Trades '871788': deal #16364229 buy 0.03 EURUSD.e at 1.21877 done (based on order #23947606) PE 0 15:31:56.834 Trades '871788': order #23947607 buy 0.04 / 0.04 USDJPY.e at 120.315 done in 64 ms CO 0 15:31:56.834 Trades '871788': order #23947608 sell 0.03 / 0.03 EURJPY.e at 146.619 done in 63 ms OR 0 15:31:56.834 Trades '871788': deal #16364230 buy 0.04 USDJPY.e at 120.315 done (based on order #23947607) GO 0 15:31:56.834 Trades '871788': deal #16364231 sell 0.03 EURJPY.e at 146.619 done (based on order #23947608) ED 0 15:33:00.526 Trades '871788': market buy 0.03 EURUSD.e ML 0 15:33:00.526 Trades '871788': market buy 0.04 USDJPY.e RH 0 15:33:00.526 Trades '871788': market sell 0.03 EURJPY.e DP 0 15:33:00.526 Trades '871788': order #23947612 buy 0.03 / 0.03 EURUSD.e at 1.21878 done in 10 ms OO 0 15:33:00.526 Trades '871788': order #23947613 buy 0.04 / 0.04 USDJPY.e at 120.315 done in 10 ms OG 0 15:33:00.526 Trades '871788': deal #16364236 buy 0.03 EURUSD.e at 1.21878 done (based on order #23947612) NE 0 15:33:00.526 Trades '871788': deal #16364237 buy 0.04 USDJPY.e at 120.315 done (based on order #23947613) LI 0 15:33:00.558 Trades '871788': order #23947614 sell 0.03 / 0.03 EURJPY.e at 146.612 done in 40 ms HG 0 15:33:00.558 Trades '871788': deal #16364238 sell 0.03 EURJPY.e at 146.612 done (based on order #23947614)以下は、API .NETによる実際のLMAXです。ニュースでのパフォーマンスは12ms、Pingは8ms（高周波タイマーを使って計測しています）これはベンチマークだと思う Mikhail Filimonov 2014.12.26 13:01 #45 olyakish:以下は、API .NETによる実際のLMAXです。ニュースでのパフォーマンスは12ms、Pingは8ms（高周波タイマーを使って計測しています）これはベンチマークだと思う Anton 2014.12.26 14:20 #46 papaklass:最後のバッチでは、注文を送信し、サーバーからの応答を1（！！）msで受信しています。そして、ログにはサーバーの処理時間が10msと表示されています。驚きです。:)という疑問が湧いてきます。端末のログで公開されているタイムは信用できるのか？ 現時点では、ログの時刻の正確さは、システムタイマーの 分解能に依存します。この場合、おそらく約16msでした（clockresユーティリティで確認できます）。この問題にも取り組んでおり、ログは改善される予定です。 Alexey Klenov 2014.12.26 14:26 #47 papaklass:最後のバッチでは、注文を送信し、サーバーからの応答を1（！！）msで受信しています。そして、ログにはサーバーの処理時間が10msと表示されています。驚きです。:)という疑問が湧いてきます。端末のログで公開されているタイムは信用できるのか？これらは、おそらく正確に16msをバラバラにしているのでしょう。15:33:00.526 であり、これらの方がより正確かもしれません。 done in 10 ms 削除済み 2014.12.26 20:31 #48 olyakish:以下は、API .NETによる実際のLMAXです。ニュースでの実行は8ms pingで12ms（高周波タイマーを使って計測）それが目安になると思います。 zaskok透明性を高めようノード間のすべての pingを引いたレイテンシーについて説明します。ロシアの取引所でHFTの人たちから1msのレイテンシーを見せられた。私は技術屋ではないので、どうやって実現しているのかはわかりません。同様にLMAXでもレイテンシは2～3ms程度です。もう一度言いますが、これはリテールレイテンシーからすべてのpingを差し引いた値です。MT5インフラは、取引所に直接接続します。あるいは、おっしゃるとおり、ただの「パイプ」です。HFTはパイプをつないで、上に書いたような結果を得るのです。MT5のパイプを接続すると、時間的なコストがかなり高くなります。その理由は何でしょうか？ レナート明確でなくてもいいから、専門家レベルの知識で。olyakish さん、本当に十分に専門的なレベルの知識をお持ちなのでしょうか？ Mikhail Filimonov 2014.12.29 10:10 #49 papaklass:1036を構築。 どのように対処しているのですか？実行力の差がモノを言う。サーバーでの性能の安定は可能ですか？追記：MTを高頻度プラットフォームとして宣伝するのはいかにも不謹慎な感じがします。:(パパグラス！そんなに「気合い」を入れる必要はないのです!わざわざ書き込みを読むこともないのか！？そして、あなたの投稿を愚直に造形すること!そろそろやめようとは思いませんか？社会人の皆さん!!!! Mikhail Filimonov 2014.12.29 10:19 #50 papaklass: 私が読むべきメッセージを示していただけませんか？レナーテの言葉を借りるならオトクリティの1035サーバーは、本日すでに稼働しています。モスクワのVPS（同じパソコン、同じリアルアカウント）から注文のトリガー時間がどのように変化したかを紹介します。2014.12.18 билд 1010 сервера 2014.12.18 10:22:33.885 Trades 'XXXXXX': buy limit 1.00 Si-3.15 at 64638 placed for execution in 72 ms 2014.12.18 10:35:05.309 Trades 'XXXXXX': exchange buy 1.00 Si-3.15 at market placed for execution in 94 ms 2014.12.18 10:35:18.937 Trades 'XXXXXX': exchange sell 1.00 Si-3.15 at market placed for execution in 148 ms 2014.12.24 билд 1035 2014.12.24 16:06:14.726 Trades 'XXXXXX': sell limit 1.00 Si-3.15 at 58837 placed for execution in 33 ms 2014.12.24 16:08:32.755 Trades 'XXXXXX': exchange sell 1.00 Si-3.15 at market placed for execution in 24 ms 2014.12.24 16:08:46.841 Trades 'XXXXXX': exchange buy 1.00 Si-3.15 at market placed for execution in 26 ms 約束通り、注文処理速度の質的な（複数の）向上が見られる。端末へのレスポンス配信で時々発生する浮遊時間はまだ解消されていませんので、引き続き取り組んでいきます。-------------------------------------------------------また、なぜ社内用と考えるのでしょうか？1) OnTradeTransactionで、注文に関する中間ステータスをいくつ取得したかを確認します。各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。10倍くらいになるような気がします。水面上に突き出たアスベルグの一片を見て、惑わされることはない。2倍ではなく、あくまで1倍ということです。これはあくまで低ベースでの効果です。とにかく、私たちは努力を続け、さらに良い結果を得るつもりです。 Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете www.mql5.com Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5 123456789101112...156 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
パパクラス さん、オリャーキッシュ さん !
の存在をRenatが確認した後、なぜこの重要なトピックで個人的なやりとりを始めたのか、その理由は定かではありません。
"端末への返信速度 "に浮遊する誤差。
また、MQによって注文執行のトラフィックを全体的に改善することを約束した。
それにしても、FXのキッチンで何をどう確認するんだ？
実際、多くの有益な情報を掲載しています。
- サーバーの構成
- ネットワークチェック方法(ping -t)。
-olyakish さんが、仮想サーバーの選択に関する作品を掲載しました。
でも、必要なさそうですね。
FXには、検証可能なものがたくさんあります。そして、取引所での操作はないと思っているのであれば、共感します。:)
パパクラス さん、オリャーキッシュ さん !
の存在をRenatが確認した後、なぜこの重要なトピックで個人的なやりとりを始めたのか、その理由は定かではありません。
"端末への返信速度 "に浮遊する誤差。
また、MQによって注文執行のトラフィックを全体的に改善することを約束した。
それにしても、FXのキッチンで何をどう確認するんだ？
以下は、API .NETによる実際のLMAXです。
ニュースでのパフォーマンスは12ms、Pingは8ms（高周波タイマーを使って計測しています）
これはベンチマークだと思う
以下は、API .NETによる実際のLMAXです。
ニュースでのパフォーマンスは12ms、Pingは8ms（高周波タイマーを使って計測しています）
これはベンチマークだと思う
最後のバッチでは、注文を送信し、サーバーからの応答を1（！！）msで受信しています。そして、ログにはサーバーの処理時間が10msと表示されています。驚きです。:)
という疑問が湧いてきます。
端末のログで公開されているタイムは信用できるのか？
最後のバッチでは、注文を送信し、サーバーからの応答を1（！！）msで受信しています。そして、ログにはサーバーの処理時間が10msと表示されています。驚きです。:)
という疑問が湧いてきます。
端末のログで公開されているタイムは信用できるのか？
これらは、おそらく正確に16msをバラバラにしているのでしょう。
であり、これらの方がより正確かもしれません。
以下は、API .NETによる実際のLMAXです。
ニュースでの実行は8ms pingで12ms（高周波タイマーを使って計測）
それが目安になると思います。
透明性を高めようノード間のすべての pingを引いたレイテンシーについて説明します。
ロシアの取引所でHFTの人たちから1msのレイテンシーを見せられた。私は技術屋ではないので、どうやって実現しているのかはわかりません。
同様にLMAXでもレイテンシは2～3ms程度です。
もう一度言いますが、これはリテールレイテンシーからすべてのpingを差し引いた値です。
MT5インフラは、取引所に直接接続します。あるいは、おっしゃるとおり、ただの「パイプ」です。HFTはパイプをつないで、上に書いたような結果を得るのです。
MT5のパイプを接続すると、時間的なコストがかなり高くなります。その理由は何でしょうか？
明確でなくてもいいから、専門家レベルの知識で。
1036を構築。
どのように対処しているのですか？実行力の差がモノを言う。
サーバーでの性能の安定は可能ですか？
追記：MTを高頻度プラットフォームとして宣伝するのはいかにも不謹慎な感じがします。:(
パパグラス！
そんなに「気合い」を入れる必要はないのです!
わざわざ書き込みを読むこともないのか！？
そして、あなたの投稿を愚直に造形すること!
そろそろやめようとは思いませんか？
社会人の皆さん!!!!
私が読むべきメッセージを示していただけませんか？
レナーテの言葉を借りるなら
オトクリティの1035サーバーは、本日すでに稼働しています。
モスクワのVPS（同じパソコン、同じリアルアカウント）から注文のトリガー時間がどのように変化したかを紹介します。
約束通り、注文処理速度の質的な（複数の）向上が見られる。
端末へのレスポンス配信で時々発生する浮遊時間はまだ解消されていませんので、引き続き取り組んでいきます。
-------------------------------------------------------
また、なぜ社内用と考えるのでしょうか？
1) OnTradeTransactionで、注文に関する中間ステータスをいくつ取得したかを確認します。
各貿易取引は1つのパケット（リクエスト・レスポンス）ではなく、複数の通知で構成されています。これは、端末が常に要求がどの段階にあるかを知るためである（例えば、実行に長い時間がかかることがある）。
現在、MQL5で中間状態の通知をすべて無効にする機能を別途搭載し、この仕組みをシンプルな形にできないかと考えています。これにより、実行速度を速めることができる。
2）取引所とのコミュニケーションの第二面、実行速度のばらつきが完全に抜けていますね。どうやら既知の0があると思っているようだが、そこには速度の保証はない。
10倍くらいになるような気がします。
水面上に突き出たアスベルグの一片を見て、惑わされることはない。
2倍ではなく、あくまで1倍ということです。これはあくまで低ベースでの効果です。
とにかく、私たちは努力を続け、さらに良い結果を得るつもりです。