SL/TP注文の受付 - ページ 2 12345678 新しいコメント Aleksey Mavrin 2020.11.25 07:29 #11 この情報は、すべてのMTメガHFTに発信されるべきです、冗談ですが))安さの代償はこれだ。 Andrey Khatimlianskii 2020.11.25 16:03 #12 fxsaber: ターミナルでさえ膨大な数の要因から遅くなることは、別のスレッドで繰り返し述べられています。その結果、より複雑なTrading Serverは、さらに速度が低下することになります。アルゴリズムによる最適化は、まだまだ可能だと期待しています。5msのラグでもすでに非常に悪い。何百ミリ秒といえばいいのか。 デモ口座については、あまり興味がありません（そこであらゆるプラグインをデバッグしたり、新しいハードウェアをテストしたりすることができます）。 そして、私はライブアカウントで最大17ミリ秒を発見した（私はそれが長くないと言っていない、それはちょうど30秒と比較することはできません）。 それゆえ、カスケード・サーバーの設定が疑われるのです。 fxsaber 2020.11.25 16:30 #13 Andrey Khatimlianskii:デモのそれは非常に興味深いものではありません（あなたはそこに任意のプラグインをデバッグすることができ、新しいハードウェアをテストし、...）。そして、ライブアカウントでは、最大17ミリ秒を確認しました（十分でないとは言いませんが、30秒とは比べものになりません）。 残念ながら、どれだけの注文をチェックしたかは表示されませんでした。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム SL/TP注文の受付 fxsaber, 2020.11.25 01:23 Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465 Calculation time = 00:04:33.609, Performance = 38.0 orders/sec. それゆえ、カスケード・サーバーの設定が疑われるのです。 ブローカーが問題を確認し、なんとか発見して修理してくれました（週末以降に公開予定）。しかし、それがMT5によるものなのかどうかは、何とも言えません。 しかし、MT5の方向に石を投げることは、このような状況によって間違いなく行うことができます。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム SL/TP注文の受付 fxsaber, 2020.11.25 00:47 ターミナルで取引するときにどうすればいいのかわからないのですが、Trading Serverでのピックが非常に低く、ターミナルで取引するときにどうすればいいのかわかりません。I.e.非常に低いpingで、Trading Server用の単一の取引アカウントを使用します。 TerminalとServerは同じマシンにあります。負荷がゼロになる。そんなアラートを新鮮な気持ちで受け止めました。 Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668 Accepted Length = 4 ms. Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED サーバーのログです。 2020.11.25 16:05:11.526 '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668] サーバーのAccept-tick。 問題があることを確認するフルスクリプトデータ。負荷がゼロの時のサーバー内部では、4msのラグがありました。 fxsaber 2020.11.25 16:46 #14 Andrei Trukhanovich:またまたfxsaberの脳内爆発です。 特に、自分がどれだけ時間を無駄にしたかを思い知ると、嫌な気分になりますね。そして、誰もあなたのためにやってはくれないということ。 Enrique Dangeroux 2020.11.25 17:05 #15 本当にサーバーに問題があるようです。デモ用MT5口座です 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1) Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1) Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec. 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1) 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1) ServerName: RannForex-Server 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1) 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1) Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1) Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1) Accepted Length = 33592 ms. 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1) Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1) 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1) Orders ( 3 ) before 1747932 with PositionID = 1747924 : 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1) ------------------------ 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1) Checked Orders = 0 同じブローカーの実際の口座では、スクリプトはゼロ結果を返します。口座での取引は3000件以上。 fxsaber 2020.11.25 17:10 #16 Enrique Dangeroux:同じブローカーの実際の口座では、スクリプトはゼロ結果を返します。口座内の取引は3,000件を超えています。 これは怪しい。私のアカウントでは、どこにもラグを発見していません。 Enrique Dangeroux 2020.11.25 17:20 #17 関連性があるかどうかはわかりませんが。でも、たくさんもらえるんですよ。 2020.11.25 16:52:52.992 Trades '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error] 位置が 変わるとTakeが発動するエラー。そこでTakeはトリガーされ、2、3回偏向した後ハングアップし、私はTpをゼロに変えてバックアップし、崩壊させました。 変える前に確認すること if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL ) ポジションがフリーズしないように。 Enrique Dangeroux 2020.11.25 17:21 #18 fxsaber :これは怪しい。私のアカウントでは、ラグがないということはどこにもありませんでした。 私もそう思っていたのですが、さらに調べてみると、Takeのクロージングだけで約100台もあることがわかりました。 だから、少ないサンプル数に fxsaber 2020.11.25 17:27 #19 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム SL/TP注文の受付 エンリケ・ダンジェルー さん 2020.11.25 17:20 関連性があるかは不明です。でも、たくさんもらえるんですよ。 2020.11.25 16:52:52.992 Trades '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error] 私のログもすべてこのようなメッセージになっています。週末が過ぎれば状況が変わるかもしれませんね。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム SL/TP注文の受付 fxsaber, 2020.11.25 16:30 ブローカーが問題を確認し、何とか発見して修正しました（週末以降に提供予定）。しかし、それがMT5によるものなのかどうかは、何とも言えません。 fxsaber 2020.11.26 08:42 #20 ここで、取引現場のいくつかのアルゴリズムを模式的に考えてみよう。簡単のために、LP（流動性供給者）は一人であると仮定します。 指値注文 LPからの価格は、取引所指値注文の価格を満たす。 ゲートウェイは、この指値注文を短い有効期限でLPに送ります。 Gateway が指値の一部についてリダイレクトを受けた場合、指値処理中に LP からの tick が変化した場合、Gateway は残りの数量について 1 から全てを繰り返す。 優れたゲートウェイ（上記のアルゴリズム）は、リミッターを実行する際、取引プラットフォームの仕様に依存しません。 アルゴリズムはほぼループしており、プラットフォームに依存しない。LPスパム対策はポイント3に含ま れる。 オープンポジションのTPレベル LPからダニが出た 価格は新しいティックとして MT5 に送信されます。 ポジションがブロックされておらず、新しいティックの価格が TP レベルを満たしている場合、MT5 は TP 注文を作成します。 GatewayはTP注文が生まれたことを確認し，ポジションをロックし，指値注文アルゴリズムのP.2を実行する。 リジャックを受信した場合、MT5 は TP 注文を拒否ステータスで履歴に送信します。ポジションのロックが解除されます。 アルゴリズムはループしておらず、プラットフォームに依存します。スパムLPからの保護があります。 このアルゴリズムには、Gateway-MT5間の通信コスト以外に2つのデメリットがある。 MT5でTP注文（ポイント3参照）の誕生にラグが あることは、このスレッドで示されています。そのため，TP注文が約定する確率は，ラグがない場合よりも低くなる。 MT5でのTP注文は、新しいティックがないと作成できません。こ れは、リダイレクトを受信した場合、MT5に新しいティックが到着し、TPレベルを満たすまで、ゲートウェイは何もしないことを意味します。そして、TPレベルを実行しようとする貴重な時間が、このために失われてしまうのです。これは、FillRateも悪化させます。 向上。 オープンポジション のTPレベルアルゴリズムにスマートゲートウェイがP.6を持っています。 6.リダイレクト中に LP から新しいティックを受信した場合、その実際の値を新しいティックとして MT5 に再送信します - ステップ 2 に移動します。 このアルゴリズムの追加ポイントは、LPスパムからの保護をまだ含んでいますが、MT5を騙してポイント3を実行させます。 そして、新しいティックを待つ貴重な時間を失うことはありません。 リアリティがある。 この2つのアルゴリズムから（2番目のアルゴリズムのポイント6の場合でも）このようになる。 MT5の指値注文は、TPレベルのオープンポジションの形で同等のものよりもFillRateが高くなります。こ のため、MT5-Hedgeのロールオーバー 時に、指値注文は実行されるが、TP注文は実行されないという状況が発生することがあります。この場合、CloseByが行われ、指値注文は対応する数量で再実行されます。 結論 MT5でFillRateを高めるには、オープンポジションのTPレベルをMT5の指値注文に転送します。 12345678 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ターミナルでさえ膨大な数の要因から遅くなることは、別のスレッドで繰り返し述べられています。その結果、より複雑なTrading Serverは、さらに速度が低下することになります。アルゴリズムによる最適化は、まだまだ可能だと期待しています。5msのラグでもすでに非常に悪い。何百ミリ秒といえばいいのか。
デモ口座については、あまり興味がありません（そこであらゆるプラグインをデバッグしたり、新しいハードウェアをテストしたりすることができます）。
そして、私はライブアカウントで最大17ミリ秒を発見した（私はそれが長くないと言っていない、それはちょうど30秒と比較することはできません）。
それゆえ、カスケード・サーバーの設定が疑われるのです。
デモのそれは非常に興味深いものではありません（あなたはそこに任意のプラグインをデバッグすることができ、新しいハードウェアをテストし、...）。
そして、ライブアカウントでは、最大17ミリ秒を確認しました（十分でないとは言いませんが、30秒とは比べものになりません）。
残念ながら、どれだけの注文をチェックしたかは表示されませんでした。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
SL/TP注文の受付
fxsaber, 2020.11.25 01:23
それゆえ、カスケード・サーバーの設定が疑われるのです。
ブローカーが問題を確認し、なんとか発見して修理してくれました（週末以降に公開予定）。しかし、それがMT5によるものなのかどうかは、何とも言えません。
しかし、MT5の方向に石を投げることは、このような状況によって間違いなく行うことができます。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
SL/TP注文の受付
fxsaber, 2020.11.25 00:47
ターミナルで取引するときにどうすればいいのかわからないのですが、Trading Serverでのピックが非常に低く、ターミナルで取引するときにどうすればいいのかわかりません。I.e.非常に低いpingで、Trading Server用の単一の取引アカウントを使用します。
TerminalとServerは同じマシンにあります。負荷がゼロになる。そんなアラートを新鮮な気持ちで受け止めました。
サーバーのログです。
サーバーのAccept-tick。
問題があることを確認するフルスクリプトデータ。負荷がゼロの時のサーバー内部では、4msのラグがありました。
またまたfxsaberの脳内爆発です。
本当にサーバーに問題があるようです。デモ用MT5口座です
同じブローカーの実際の口座では、スクリプトはゼロ結果を返します。口座での取引は3000件以上。
同じブローカーの実際の口座では、スクリプトはゼロ結果を返します。口座内の取引は3,000件を超えています。
これは怪しい。私のアカウントでは、どこにもラグを発見していません。
関連性があるかどうかはわかりませんが。でも、たくさんもらえるんですよ。
位置が 変わるとTakeが発動するエラー。そこでTakeはトリガーされ、2、3回偏向した後ハングアップし、私はTpをゼロに変えてバックアップし、崩壊させました。
変える前に確認すること
ポジションがフリーズしないように。
これは怪しい。私のアカウントでは、ラグがないということはどこにもありませんでした。
私もそう思っていたのですが、さらに調べてみると、Takeのクロージングだけで約100台もあることがわかりました。
だから、少ないサンプル数に
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
SL/TP注文の受付
エンリケ・ダンジェルー さん 2020.11.25 17:20
関連性があるかは不明です。でも、たくさんもらえるんですよ。
私のログもすべてこのようなメッセージになっています。週末が過ぎれば状況が変わるかもしれませんね。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
SL/TP注文の受付
fxsaber, 2020.11.25 16:30
ブローカーが問題を確認し、何とか発見して修正しました（週末以降に提供予定）。しかし、それがMT5によるものなのかどうかは、何とも言えません。
ここで、取引現場のいくつかのアルゴリズムを模式的に考えてみよう。簡単のために、LP（流動性供給者）は一人であると仮定します。
指値注文
優れたゲートウェイ（上記のアルゴリズム）は、リミッターを実行する際、取引プラットフォームの仕様に依存しません。
アルゴリズムはほぼループしており、プラットフォームに依存しない。LPスパム対策はポイント3に含ま れる。
オープンポジションのTPレベル
アルゴリズムはループしておらず、プラットフォームに依存します。スパムLPからの保護があります。
このアルゴリズムには、Gateway-MT5間の通信コスト以外に2つのデメリットがある。
向上。
オープンポジション のTPレベルアルゴリズムにスマートゲートウェイがP.6を持っています。
このアルゴリズムの追加ポイントは、LPスパムからの保護をまだ含んでいますが、MT5を騙してポイント3を実行させます。 そして、新しいティックを待つ貴重な時間を失うことはありません。
リアリティがある。
この2つのアルゴリズムから（2番目のアルゴリズムのポイント6の場合でも）このようになる。
MT5の指値注文は、TPレベルのオープンポジションの形で同等のものよりもFillRateが高くなります。こ のため、MT5-Hedgeのロールオーバー 時に、指値注文は実行されるが、TP注文は実行されないという状況が発生することがあります。この場合、CloseByが行われ、指値注文は対応する数量で再実行されます。
結論
MT5でFillRateを高めるには、オープンポジションのTPレベルをMT5の指値注文に転送します。