2016.07.0711:07:19.518 Trades 'xxxxx': deal #27055429 sell 1.00 RTS-9.16 at 91800 done (based on order #38972998)
2016.07.0711:07:19.508 Trades 'xxxxx': exchange sell 1.00 RTS-9.16 at market placed for execution in5 ms
2016.07.0711:07:19.502 Trades 'xxxxx': exchange sell 1.00 RTS-9.16 at market
2016.07.0711:07:13.542 Trades 'xxxxx': deal #27055426 buy 1.00 RTS-9.16 at 91820 done (based on order #38972992)
2016.07.0711:07:13.532 Trades 'xxxxx': exchange buy 1.00 RTS-9.16 at market placed for execution in5 ms
2016.07.0711:07:13.527 Trades 'xxxxx': exchange buy 1.00 RTS-9.16 at market
2016.07.0711:07:11.391 Trades 'xxxxx': cancel order #38972986 buy limit 1.00 RTS-9.16 at 91740 placed for execution in6 ms
2016.07.0711:07:11.385 Trades 'xxxxx': cancel order #38972986 buy limit 1.00 RTS-9.16 at 917402016.07.0711:07:04.850 Trades 'xxxxx': buy limit 1.00 RTS-9.16 at 91740 placed for execution in5 ms
2016.07.0711:07:04.844 Trades 'xxxxx': buy limit 1.00 RTS-9.16 at 917402016.07.0711:06:39.281 Network 'xxxxx': trading has been enabled - netting mode
2016.07.0711:06:39.281 Network 'xxxxx': terminal synchronized with АО '' Открытие Брокер''2016.07.0711:06:39.274 Network 'xxxxx': previous successful authorization performed from xxxxxxxxxxxx
2016.07.0711:06:39.274 Network 'xxxxx': authorized on Open-Broker through Access Server V (ping: 1.98 ms)
今のところ両アカウントともOpenでやっていて、平均pingはまあまあです。異なるリソースへのpingを確認してください。多分、問題はISP側にあります。
Pingは問題ない。
デモと実機で問題があったのは不思議です。サーバーが違うんですよ...取引実験の時に開発者がおかしくなったんじゃないかと思い始めていました）。
多分、私個人としては不具合を課されたのでは？）
キャンセルオーダー #38968458 売り指値1.00 Si-9.16 at 65888 65606ミリ秒で執行されました。
返信ありがとうございました。それは変ですね。
私はそれを調べるでしょう。
Pingは問題ない。
デモと実機で問題があったのは不思議です。サーバーが違うんですよ...取引実験の時に開発者がおかしくなったんじゃないかと思い始めていました）。
多分、私個人としては不具合を課されたのでは？）
キャンセルオーダー #38968458 売り指値1.00 Si-9.16 at 65888 65606ミリ秒で執行されました。
返信ありがとうございました。それは変ですね。
私はそれを調べるでしょう。
Pingはどのように計測するのですか？サーバーが違うから変なんだよ。65秒は宇宙的な遅さ、むしろバグに近い。65秒後のチャートにも注文が表示されるのでしょうか？
Pingはどのように計測するのですか？サーバーが違うから変なんだよ。65秒は宇宙的な遅さ、むしろバグに近い。チャート上では、65秒後に注文も表示されるのでしょうか？
そうですね、1分後にも、時には20～30秒後にも早いですね。
しかし、あるサービスでネットから未知の何かを自動ダウンロードした後、なぜかすべてが再び「飛ぶ」ようになったのです。でも、たぶん関係ないんでしょうね。
夜、Windows 10を以前のビルドに「ロールバック」したのが原因かもしれません。 ...でも、そんなことはないはず...。偶然の一致です。
何だったんだろう。
今後も注視していきたい。二度と起こらないことを祈っています。
ここでは、実際のアカウントからだけ 紹介します。
買い指値の設定、解除、成行注文、成行決済を5ms以内、Pingは2msで実行。モスクワのMetaTrader VPS Serverから です。
リアルアカウントから 来ました。
買い指値の設定、解除、成行注文、成行決済を2msのPINGで5ms以内に行う。モスクワのMetaTrader VPS Serverから です。
私も今は元気ですよ。何事も早いですね。つまり、私の遅れはあなたの仕業ではなく、あなたは何の実験もしていないことがわかったのです。
あなたのブローカーは、意図的に個々の "松葉杖 "を投げるために技術的な可能性を持っていますか？(例えば遊びで)。
これらの遅れは、Windows 10を使った実験による「奇跡」によるものであってほしいと願っています。
買い指値1.00 RTS-9.16 at917405ミリ秒で約定
このラグでハードアービトラージに挑戦することもできるんだ!!!
私のpingは60msで、私のソフトスキャルパー戦略には十分です)
私も今は元気ですよ。何事も早いですね。つまり、私の遅延はあなたの手によるものでもなく、実験もしていないことがわかったのです。
現在、取引所はインフラのアップグレードを進めており、最近、新しいバージョンのAPIをロールアウトしました。異なるプラットフォームや自身のコネクターで取引するトレーダーから、約定時間が浮いている、明らかに遅いという苦情が多数寄せられています。
ほとんどの場合、これらは一時的な問題であり、交換により修正されます。このような遅延が発生することは利益にならない。
ブローカーは、わざと松葉杖を投げ入れるような技術力を持っているのでしょうか？(例えば遊びで)。
これらの遅れは、Windows 10の実験による "奇跡 "であってほしい。
このディレイを使えば、ハードアービトラージも可能です。
私のpingは60msで、私のソフトスキャルパー戦略には十分です)
新リリースとブローカーサーバーの更新後、取引実行時間と取引 全体のレイテンシーは、さらに数ミリ秒改善される予定です。
すべての取引所のチューニングに力を入れ、プロセスチェーンにおける100マイクロ秒単位の勝負に挑んでいるのです。
いいえ、ゲートウェイは完全に取引所と直接つながっており、ブローカーは干渉することができません。
つまり、注文はまずサーバーに送られ、そこで処理され、正しいかどうかチェックされた後、ゲートウェイに送られるようです。
https://www.mql5.com/ru/docs/trading/ordersend
"トレード "のリクエストは、トレードサーバー上でいくつかの段階を経て検証されます。"
つまり、取引所に届く前（バリデーション中）に、ブローカーは（理論的には、開発者が提供すれば）それを「いじる」機会があるのです。DMAを使うトレーダーのポストトレードコントロールとは違うのです。
あるいは、交換版の場合、リクエストの正しさをチェックする機能は端末自体が行うので（サーバーとともに全トランザクションの記録を保持し、非同期にやり取りする）、サーバーに追加の計算の負担をかけないということでしょうか。しかし、そうするとENUM_ORDER_STATEに こんなに多くのステートが存在しないことになります。
それとも私が誤解しているのでしょうか？
今回のリリースとブローカーサーバーの更新により、取引実行時間と取引 全体のレイテンシーがさらに数ミリ秒改善される予定です。
すべての取引所のチューニングに力を入れ、プロセスチェーンにおける100マイクロ秒単位の勝負に挑んでいるのです。
かっこいいですね。でも、イマドキは実行速度に問題はないんですよ。なぜさらに増やすのか？スピードの面で、他にどのような競合プラットフォームを「罰する」べきなのか。この点では、クイックはすでに負けている。
plazaのドキュメントを見ていて気がつきませんでしたが、もしfuturesでなんとか物事を立ち上げることができたのなら - オプション機能を立ち上げるのは絶対に簡単で時間のかからないことなはずなんです。
ただ、まだ選択肢がない(
もちろん、秘密でなければ教えてください。
ディスカバリーのサーバーをアップデートしてから、お伝えします。
それくらいあることがほとんどです。
2016.07.07 11:47:11.564 トレード '10644': 65057 (65057) で買い指値 1.00 Si-9.16 tp: 65457 が 7 ms で実行に置かれました。
2016.07.07 11:47:11.557 トレード '10644': 65057 (65057) で買い指値 1.00 Si-9.16 tp: 65457
リクエストはまずサーバーに送られ、そこで処理され、正しいかどうかチェックされた後、ゲートウェイに送られるようです。
https://www.mql5.com/ru/docs/trading/ordersend
"トレード "のリクエストは、トレードサーバー上でいくつかの段階を経て検証されます。"
サーバーは注文の全体的な正しさをチェックし、ゲートウェイに直接送信する。
ありがとうございます。 とにかく、QuickBooksと比較すると（ログによると）実行速度が速いのが印象的です。
もうひとつ、あなた以外の人にはなかなか答えられない、重要な問題があります。ご回答いただけると幸いです。
1）MarketDataの速さです。引用の妥当性を確認する方法は？
交換はマイクロ秒単位で換算され、プラザで入手できます。
bid_changed t 現在の最良入札見積りの変更時刻。
ask_changed t 現在の最良の売り気配が変化した時刻。
メタトレーダーは、サーバー時間（秒）と最良価格の値のみです。
価格変動の交換時間に加えて、MTが交換サーバーの時刻と定期的に同期しているms単位の時刻をブロードキャストする場合
- そうすれば、問題は解決したはずです。すべてがうまくいく！？
もし、古い相場によって盲目的に取引を決定するのであれば、執行速度は重要ではありません。時々、（理由はどうあれ）本当に不調になることがある。そして、そのようなときに取引をするのは避けたいものです。
//---------------
2) コピーティックで全てのティックを要求した場合、MqlTick構造 体の tick.time_msc(最終価格更新の時間、ミリ秒) は、サーバー時間と一致する秒単位に丸められた時間を出力します。time// 最終価格更新 時刻と同じ。なぜ必要なものではないのか - 交換時間と取引時間......？プラザ経由で入手することができます。そして、MT5はそこから情報を取得する...。この質問に対する回答は、サービスデスクにはありません（！）。