MT5とスピードの関係 - ページ 92 1...85868788899091929394 新しいコメント Vasiliy Pushkaryov 2021.07.29 14:21 #911 fxsaber:TimeLocalとTimeCurrentの 不一致を監視する。 また、このような状況でTimeLocal()が遅延するとしたら、原因はOSにあるのでしょうか？ fxsaber 2021.07.29 14:22 #912 Vasiliy Pushkaryov: また、このような状況でTimeLocal()が遅れるとしたら、原因はOSにあるのでしょうか？ TimeLocalも負けては いません。その齟齬はブローカーである。 Andrei Trukhanovich 2021.07.29 14:32 #913 Vasiliy Pushkaryov:もしかしたら、どなたかが経験されているかもしれませんが、このようなしゃっくりやブレーキの原因は何でしょうか？ まず思いつくのは、計算が非常に長い時間実行されるコードのバグです（例えば、1から10までのサイクルでは、バグのために全部のintが実行されます）。 Vasiliy Pushkaryov 2021.07.29 14:41 #914 fxsaber:TimeLocalも負けては いません。その齟齬はブローカーである。 ありがとうございます。試してみます。 Vasiliy Pushkaryov 2021.07.29 14:49 #915 Andrei Trukhanovich:まず思い浮かぶのは、非常に長い時間を要する計算を誘発するコードのバグです（例えば、1から10までのサイクルでは、バグのためにint全体が実行されます）。 ループしたEAが他のプログラムの動作を乱すことはできないとヘルプに書かれています。すべてがフリーズし、再び動き出す。 MT4端子7台とMT5端子3台を並列に走らせています。容量が足りないのでは？ Andrei Trukhanovich 2021.07.29 15:09 #916 Vasiliy Pushkaryov:ループしたEAが他のプログラムを混乱させることはできないとヘルプに書いてあるようです。そして、ここですべてがフリーズし、その後、すべてが再び動き出す。 ああ、不思議だ、エキスパートタブしか見てない、初回はログを見てないんだ。 MT4端子7台とMT5端子3台が並列に稼働しています。容量が足りないのでは？ もしそうなら、ほとんどの場合、すべての端末がスローダウンすることになる。さらに、この場合、CPU負荷はちょうど100%になるはずです。 fxsaber 2021.08.02 20:47 #917 セットTerminalA - アクセスポイントへのPingデータ（xxx ms）を持っている端末。 セットTerminalB - アクセスポイントへのPingデータがない(n/a)端末。 両方の端末を同じアクセスポイントに接続し、同じようにOrderSendを 送信し、レスポンスを受信して取引することができます。 TerminalAでは、プロセッサへの負荷を可能な限り小さくしています。 TerminalB: は、できるだけCPUに負荷をかけます。 を再起動すると、TerminalBのままです。 ネットワークの再スキャン」（GUIによる手動）後、タイプをTerminalAに変更する。それに伴い、CPUへの負荷も停止します。 どうしようもなくCPU負荷が高い場合は、再スキャンを試してみてください。このおかげで、TerminalBをすべてTerminalAに変更することができました。 fxsaber 2021.08.30 06:50 #918 なぜかわかりませんが、私のブローカーはMT4よりもMT5の方が取引高、取引数、アクティブな取引口座の数が多いようです。 残念ながら、プラットフォーム別の集計情報しかありません。 Количество закрытых позиций :129 714 Торговый оборот ($) :$ 5 747 296 372 Активных счетов :498 しかし、状況証拠ではMT5がMT4より先を行っているようです。このような状態になった理由は、推測するしかない。 クライアントについて知っていること。 >取引の95%以上(取引高の99%以上)が自動売買です。 一部のクライアントでは、MT5端末が10ギガ以上のメモリ（履歴キャッシュ）を消費し、同じボリュームのMT4は1ギガ未満です。にもかかわらず、より強力なVPSに過払いする準備ができていますが、4ではなく、MT5で正確に取引しています。 ほとんど全部がダフ屋です。主な収益は、夜間・夕方のフラット取引で占められています。 ロールオーバー期間中の高いアクティビティ（他のブローカーと比較してプラス面へ） - 巨大なスプレッド。 Vasiliy Pushkaryov 2021.09.28 10:06 #919 fxsaber TimeCurrentの 不一致を監視する。 ご指摘ありがとうございます。この状況をキャッチした。OnTimer()でTimeLocal() とTimeCurrent()のズレを監視する 昨日の夕方21:58からTimeCurrent() が同じ時刻を返すようになりました。本日00:08にリリースされました。つまり、2時間強は全キャラクターからこのような状況になっていたのです。 fxsaber 2022.01.19 10:28 #920 リモートマシン（VPSではない）でスペックが良く、取引サーバーへのpingが4ms未満で、Terminallogsを 見ると定期的にラグが発生するケースが多く見られました（b2958）。 最初に見たデモ用をここに持ってきた。 2022.01.18 23:00:09.375 Trades '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.752 Trades '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.769 Trades '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms リミッターの変更は8秒間続いた。ほとんどの改造は、そのくらいの時間がかかります。 2022.01.18 23:11:00.751 Trades '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.761 Trades '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.763 Trades '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms 4msのpingでも多いが、それでも8秒に比べれば大したことはない。 このマシンではMT5端末のみが稼働しており、平均的なCPU負荷は〜1％です。解析の結果、市場や取引注文が非常に活発な場合、ブレーキ時の負荷が100%まで急上昇することがわかりました。その結果、取引サーバーから端末に応答が届くまでに非常に長い時間がかかってしまいます。遅い場合は、ブローカーに問い合わせています。トレードサーバー側では、すべてが瞬時に行われ、注文は最初の行でターミナルからサーバーに到達します。例えば、注文の送信は遅くならず、端末への応答を受信するときにラグが発生します。 開発者がここで何かを改善することはできないでしょう。トレードでVERYアクティブな人、このトピックに関する考察を過去ログで教えてください。 1...85868788899091929394 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
TimeLocalとTimeCurrentの 不一致を監視する。
また、このような状況でTimeLocal()が遅れるとしたら、原因はOSにあるのでしょうか？
TimeLocalも負けては いません。その齟齬はブローカーである。
もしかしたら、どなたかが経験されているかもしれませんが、このようなしゃっくりやブレーキの原因は何でしょうか？
まず思いつくのは、計算が非常に長い時間実行されるコードのバグです（例えば、1から10までのサイクルでは、バグのために全部のintが実行されます）。
TimeLocalも負けては いません。その齟齬はブローカーである。
まず思い浮かぶのは、非常に長い時間を要する計算を誘発するコードのバグです（例えば、1から10までのサイクルでは、バグのためにint全体が実行されます）。
ループしたEAが他のプログラムの動作を乱すことはできないとヘルプに書かれています。すべてがフリーズし、再び動き出す。
MT4端子7台とMT5端子3台を並列に走らせています。容量が足りないのでは？
ループしたEAが他のプログラムを混乱させることはできないとヘルプに書いてあるようです。そして、ここですべてがフリーズし、その後、すべてが再び動き出す。
ああ、不思議だ、エキスパートタブしか見てない、初回はログを見てないんだ。
MT4端子7台とMT5端子3台が並列に稼働しています。容量が足りないのでは？
もしそうなら、ほとんどの場合、すべての端末がスローダウンすることになる。さらに、この場合、CPU負荷はちょうど100%になるはずです。
セットTerminalA - アクセスポイントへのPingデータ（xxx ms）を持っている端末。
セットTerminalB - アクセスポイントへのPingデータがない(n/a)端末。
両方の端末を同じアクセスポイントに接続し、同じようにOrderSendを 送信し、レスポンスを受信して取引することができます。
TerminalAでは、プロセッサへの負荷を可能な限り小さくしています。
TerminalB:
どうしようもなくCPU負荷が高い場合は、再スキャンを試してみてください。このおかげで、TerminalBをすべてTerminalAに変更することができました。
なぜかわかりませんが、私のブローカーはMT4よりもMT5の方が取引高、取引数、アクティブな取引口座の数が多いようです。
残念ながら、プラットフォーム別の集計情報しかありません。
しかし、状況証拠ではMT5がMT4より先を行っているようです。このような状態になった理由は、推測するしかない。
クライアントについて知っていること。
ご指摘ありがとうございます。この状況をキャッチした。OnTimer()でTimeLocal() とTimeCurrent()のズレを監視する
昨日の夕方21:58からTimeCurrent() が同じ時刻を返すようになりました。本日00:08にリリースされました。つまり、2時間強は全キャラクターからこのような状況になっていたのです。
リモートマシン（VPSではない）でスペックが良く、取引サーバーへのpingが4ms未満で、Terminallogsを 見ると定期的にラグが発生するケースが多く見られました（b2958）。
最初に見たデモ用をここに持ってきた。
2022.01.18 23:00:09.375 Trades '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.752 Trades '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.769 Trades '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 msリミッターの変更は8秒間続いた。ほとんどの改造は、そのくらいの時間がかかります。
2022.01.18 23:11:00.751 Trades '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.761 Trades '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.763 Trades '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms4msのpingでも多いが、それでも8秒に比べれば大したことはない。
このマシンではMT5端末のみが稼働しており、平均的なCPU負荷は〜1％です。解析の結果、市場や取引注文が非常に活発な場合、ブレーキ時の負荷が100%まで急上昇することがわかりました。その結果、取引サーバーから端末に応答が届くまでに非常に長い時間がかかってしまいます。遅い場合は、ブローカーに問い合わせています。トレードサーバー側では、すべてが瞬時に行われ、注文は最初の行でターミナルからサーバーに到達します。例えば、注文の送信は遅くならず、端末への応答を受信するときにラグが発生します。
開発者がここで何かを改善することはできないでしょう。トレードでVERYアクティブな人、このトピックに関する考察を過去ログで教えてください。