MT5とスピードの関係 - ページ 44 1...373839404142434445464748495051...94 新しいコメント Renat Fatkhullin 2020.10.05 21:22 #431 fxsaber:ターミナルがCPUに100％負荷をかけて、何も反応しない状況を何度も見たことがあります。そこでログを見ると、OnTickでtickが乱れ飛んでいるのが確認できました。しかし、私が正しくEAを作成すれば、このような悲惨な状況でも取引結果に影響を与えることはありません。具体的に分析したところ、すべてがクリアになりました。Market Productsの遅延に対応する仕組みがどれだけ普及しているのか気になるところです。マシンパワーで動くという話は一度も見たことがない。最小pingは「はい」です。 どこで発売していたのですか？ 2〜5ドルのVPSで あれば、数十ミリ秒、数百ミリ秒の遅延は、ほとんど深刻なWinAPI関数で簡単に捕捉されます。ハイパーバイザーレベルからすべてが遅くなり、仮想マシンがスライドショーになってしまうのです。 上記で説明しています。 Andrey Khatimlianskii 2020.10.05 21:23 #432 Renat Fatkhullin:遅くなるのはGetMicrosecondsCountではなく、OSが絞られたVPS内の任意のスレッドのCPUリソースを数値化しているのです。UPU内のあらゆる機能、アクション、プログラムに対して。まあ、1コピーあたり1500スレッドも実行するOSが20個（これでも立派な方）もあれば、どんなCPUシェルでも公平にリソースをスライスして割り当てられるわけがないんですけどね。8〜16コアを20×1,500＝30,000（3万本の物理トラック）に分散させる。 私の場合（vin7＋2コア＋16GBのRAMを搭載した仮想ボックス、完全に自前のハードウェアで他に何も実行 しない）、周期的な2-3μsはどこから来るのでしょうか？ トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム MT5と戦闘時のスピード アンドレイ・ハチムリアンスキー さん 2020.10.05 10:19 UPUというわけではなく、レンタルしたハードウェア上に仮想マシンを搭載している。 2020.09.29 00:11:11.350 Terminal MetaTrader 5 x64 build 2615 started for MetaQuotes Software Corp. 2020.09.29 00:11:11.352 Terminal Windows 7 Service Pack 1 build 7601 on Virtual Box, Intel Core i7-4770 @ 3.40 GHz, 14 / 15 Gb memory, 4 / 31 Gb disk, IE 11, Admin, GMT+2 2020.10.05 11:11:25.340 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:11:31.308 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:12:34.699 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 3 mсs. 2020.10.05 11:13:04.388 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:13:58.116 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:14:08.388 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:14:14.975 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:14:19.095 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:15:28.814 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:15:55.814 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:15:56.814 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:16:27.818 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 9 mсs. 2020.10.05 11:16:35.275 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:16:45.775 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 27 mсs. 2020.10.05 11:16:51.715 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. 2020.10.05 11:17:30.477 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 5 mсs. 2020.10.05 11:18:25.081 test (GBPUSD,M15) Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs. Renat Fatkhullin 2020.10.05 21:30 #433 Andrey Khatimlianskii:私の場合（win7＋2コア＋16GBのRAMを搭載した仮想ボックスで、他に何も回転していない独自の ハードウェア）、周期的な2-3μsはどこから来るのでしょうか？ それがデュアル仮想化の代償です。 特にVirtualBoxは本格的なHyper-Vタイプのハイパーバイザーではなく、別の用途のためにCPUシェルを立ち上げた現在のデスクトップ OS(Windows 7も？)の上に乗っているのですから。 つまり、Windows 7/10 -> VirtualBox -> Windows 7 というように、2段階の仮想化が可能で、最初の人はVirtualBoxの目的を知らず、普通のプログラムとして見ているのです。CPUのリソース割り当て（スレッドシェジュラー）が明らかに狂っている。 そうでなければならない。Hyper-V 2016/2019 -> Windows 2016/2019 fxsaber 2020.10.05 21:32 #434 Renat Fatkhullin:遅くなるのはGetMicrosecondsCountではなく、絞られたVPS内のあらゆるスレッドのCPUリソースを数値化しているOSの方なのです。UPU内のあらゆる機能、アクション、プログラムに対して。 こういう議論があると、考えさせられると思うんです。アドバイザー #include <fxsaber\Benchmark\Benchmark.mqh> // https://www.mql5.com/ru/code/31279 // Сделал действия по этой ссылке: https://www.mql5.com/ru/forum/342090/page41#comment_18597040 void OnStart() { _BV( for (int i = 0; i < 1 e6; i++) GetMicrosecondCount(); , 1) _BV( for (int i = 0; i < 1 e6; i++) GetTickCount(); , 1) } 2020.10.06 00:24:26.779 Alert: Time[Test6.mq5 52: for(inti=0;i<1 e6;i++)GetMicrosecondCount();] = 16289902 mсs. 2020.10.06 00:24:26.784 Alert: Time[Test6.mq5 57: for(inti=0;i<1 e6;i++)GetTickCount();] = 4300 mсs. ここまでが、すべてをスローダウンさせること。そのため、winmm::timeBeginPeriod(1)+winmm::timeGetTime()に変更しても全く問題なく、GetTickCountと同様の速度が得られ、かつ恐ろしい16ms制限もないのです。しかし、Market-producerはDLLなので、これを行うことはできません。ミリ秒の通常版は作れそうにないですね。 fxsaber 2020.10.05 21:36 #435 Renat Fatkhullin:MQL5の機能で、すべてのウィンドウとアプリケーション自体を最小化するのは素晴らしいアイデアだと思います。そのために努力します。ここでもうひとつ。 VPSで 自分の端末を動かして いる人は、突然すべてをロールオーバーされることに強く反発するはずです。RDPセッションから離れる場合は、自分でウィンドウズを最小化することができますし、そうすべきです。 現在、WinAPIを使用してホットキーで最小化するようにしています。非常に便利で、標準の TerminalClose よりもはるかに無害です。 Roman 2020.10.05 21:36 #436 Renat Fatkhullin: 以下は、私が言いたかったことの一例です。 両方のサーバーが異なるブローカーである、同じ地域にある、同じ場所にあることができる。 サービスカードには、AMPが英国にあることが示唆されています。 そして、NLでJust for some reason offers. なぜ？近いvpcがある場合。 Renat Fatkhullin 2020.10.05 21:43 #437 fxsaber:考えさせられる議論だと思います。カウンセラーです。ここまでがスローダウン。そのため、winmm::timeBeginPeriod(1)+winmm::timeGetTime()に変更しても全く問題なく、GetTickCountと同様の速度が得られ、かつ恐ろしい16ms制限を受けないようにすることができました。しかし、Market-producerはDLLなので、これを行うことはできません。ミリ秒の通常版をやることはまずないでしょう。 相関関係や合理性のないストレステストのレースの達人ですね。 もちろん、マイクロ秒計測には、ミリ秒の1000倍の間隔を計測できるリソースが必要だ。 超精密な間隔を測定する必要がある 場合は、マイクロ秒を使用します。そして、そのコストは0マイクロ秒になります。 数百万回を自己測定と呼ぶ設定なら、自己欺瞞に陥っているのだろう。 息の詰まるようなVPSでは、timeBeginPeriodによるシステムタイマーの オーバークロックは危険です。CPUのオーバーヘッドが増えるだけです。 この機能は、Windowsのグローバルな設定に影響します。Windowsは、どのプロセスからも要求された最も低い値（つまり、最も高い解像度）を使用します。解像度を高く設定することで、待ち受け機能のタイムアウト間隔の精度を向上させることができます。しかし、スレッドスケジューラがタスクを切り替える頻度が高くなるため、システム全体のパフォーマンスを低下させる可能性もあります。また、高解像度の場合、CPUのパワーマネジメント・システムが省電力モードに入るのを妨げることがあります。高い分解能を設定しても、高分解能パフォーマンスカウンターの精度は向上しません。 そうでなければ、OSはとっくの昔に正確なGetTickCount/GetTickCount64を作り、自由な精度で喜ぶべきだったのです。しかし、いや、このタイマーの正確さには代償を払わなければならない。 fxsaber 2020.10.05 21:44 #438 CHART_IS_MAXIMIZEDの ブレーキを 解除してください。WinAPIソリューションは、純正と比較して一桁も速くなくなりました。 Renat Fatkhullin 2020.10.05 21:49 #439 Roman:以下は、私が言いたかったことの一例です。 両方のサーバーが異なるブローカーである、同じ地域にある、同じ場所にあることができる。 サービスカードには、AMPが英国にあることが示唆されています。 そして、NLでJust for some reason offers. なぜ？PSTNクローザーがある場合。 サーバーの地理的な位置がわかっており、ここではGeoIPをベースにブローカーサーバーの位置を構築しています。 そして、その情報が現実に即していないこともよくあることです。したがって、ブローカーのポジションが正確であるとは決して考えない方がよいでしょう。 質問に答えるためには、すべてを手作業でダブルチェックし、再スキャンする必要があるので、明日、詳しく調べます。 Andrey Khatimlianskii 2020.10.05 21:49 #440 Renat Fatkhullin:それがデュアル仮想化の代償です。特にVirtualBoxはHyper-Vタイプのフルハイパーバイザーではなく、異なるユースケースに合わせたCPUシェルを持つ現在のデスクトップ OS（Windows 7もか）の上に乗っているのですから。つまり、Windows 7/10 -> VirtualBox -> Windows 7 というように、2段階の仮想化が可能で、最初の人はVirtualBoxの目的を知らず、普通のプログラムとして見ているのです。CPUのリソース割り当て（スレッドシェジュラー）が明らかに狂っている。そうでなければならない。Hyper-V 2016/2019 -> Windows 2016/2019 いや、俺のCentOSには仮想化装置が回ってるんだけどね。しかし、私はこの対話を続ける能力がない。 1...373839404142434445464748495051...94 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ターミナルがCPUに100％負荷をかけて、何も反応しない状況を何度も見たことがあります。
そこでログを見ると、OnTickでtickが乱れ飛んでいるのが確認できました。しかし、私が正しくEAを作成すれば、このような悲惨な状況でも取引結果に影響を与えることはありません。具体的に分析したところ、すべてがクリアになりました。
Market Productsの遅延に対応する仕組みがどれだけ普及しているのか気になるところです。マシンパワーで動くという話は一度も見たことがない。最小pingは「はい」です。
どこで発売していたのですか？
2〜5ドルのVPSで あれば、数十ミリ秒、数百ミリ秒の遅延は、ほとんど深刻なWinAPI関数で簡単に捕捉されます。ハイパーバイザーレベルからすべてが遅くなり、仮想マシンがスライドショーになってしまうのです。
上記で説明しています。
遅くなるのはGetMicrosecondsCountではなく、OSが絞られたVPS内の任意のスレッドのCPUリソースを数値化しているのです。UPU内のあらゆる機能、アクション、プログラムに対して。
まあ、1コピーあたり1500スレッドも実行するOSが20個（これでも立派な方）もあれば、どんなCPUシェルでも公平にリソースをスライスして割り当てられるわけがないんですけどね。8〜16コアを20×1,500＝30,000（3万本の物理トラック）に分散させる。
私の場合（vin7＋2コア＋16GBのRAMを搭載した仮想ボックス、完全に自前のハードウェアで他に何も実行 しない）、周期的な2-3μsはどこから来るのでしょうか？
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MT5と戦闘時のスピード
アンドレイ・ハチムリアンスキー さん 2020.10.05 10:19
UPUというわけではなく、レンタルしたハードウェア上に仮想マシンを搭載している。
私の場合（win7＋2コア＋16GBのRAMを搭載した仮想ボックスで、他に何も回転していない独自の ハードウェア）、周期的な2-3μsはどこから来るのでしょうか？
それがデュアル仮想化の代償です。
特にVirtualBoxは本格的なHyper-Vタイプのハイパーバイザーではなく、別の用途のためにCPUシェルを立ち上げた現在のデスクトップ OS(Windows 7も？)の上に乗っているのですから。
つまり、Windows 7/10 -> VirtualBox -> Windows 7 というように、2段階の仮想化が可能で、最初の人はVirtualBoxの目的を知らず、普通のプログラムとして見ているのです。CPUのリソース割り当て（スレッドシェジュラー）が明らかに狂っている。
そうでなければならない。Hyper-V 2016/2019 -> Windows 2016/2019
遅くなるのはGetMicrosecondsCountではなく、絞られたVPS内のあらゆるスレッドのCPUリソースを数値化しているOSの方なのです。UPU内のあらゆる機能、アクション、プログラムに対して。
こういう議論があると、考えさせられると思うんです。アドバイザー
ここまでが、すべてをスローダウンさせること。そのため、winmm::timeBeginPeriod(1)+winmm::timeGetTime()に変更しても全く問題なく、GetTickCountと同様の速度が得られ、かつ恐ろしい16ms制限もないのです。しかし、Market-producerはDLLなので、これを行うことはできません。ミリ秒の通常版は作れそうにないですね。
MQL5の機能で、すべてのウィンドウとアプリケーション自体を最小化するのは素晴らしいアイデアだと思います。そのために努力します。
ここでもうひとつ。
VPSで 自分の端末を動かして いる人は、突然すべてをロールオーバーされることに強く反発するはずです。RDPセッションから離れる場合は、自分でウィンドウズを最小化することができますし、そうすべきです。
以下は、私が言いたかったことの一例です。
両方のサーバーが異なるブローカーである、同じ地域にある、同じ場所にあることができる。
サービスカードには、AMPが英国にあることが示唆されています。
そして、NLでJust for some reason offers.
なぜ？近いvpcがある場合。
考えさせられる議論だと思います。カウンセラーです。
ここまでがスローダウン。そのため、winmm::timeBeginPeriod(1)+winmm::timeGetTime()に変更しても全く問題なく、GetTickCountと同様の速度が得られ、かつ恐ろしい16ms制限を受けないようにすることができました。しかし、Market-producerはDLLなので、これを行うことはできません。ミリ秒の通常版をやることはまずないでしょう。
相関関係や合理性のないストレステストのレースの達人ですね。
もちろん、マイクロ秒計測には、ミリ秒の1000倍の間隔を計測できるリソースが必要だ。
超精密な間隔を測定する必要がある 場合は、マイクロ秒を使用します。そして、そのコストは0マイクロ秒になります。
数百万回を自己測定と呼ぶ設定なら、自己欺瞞に陥っているのだろう。
息の詰まるようなVPSでは、timeBeginPeriodによるシステムタイマーの オーバークロックは危険です。CPUのオーバーヘッドが増えるだけです。
そうでなければ、OSはとっくの昔に正確なGetTickCount/GetTickCount64を作り、自由な精度で喜ぶべきだったのです。しかし、いや、このタイマーの正確さには代償を払わなければならない。
以下は、私が言いたかったことの一例です。
両方のサーバーが異なるブローカーである、同じ地域にある、同じ場所にあることができる。
サービスカードには、AMPが英国にあることが示唆されています。
そして、NLでJust for some reason offers.
なぜ？PSTNクローザーがある場合。
サーバーの地理的な位置がわかっており、ここではGeoIPをベースにブローカーサーバーの位置を構築しています。
そして、その情報が現実に即していないこともよくあることです。したがって、ブローカーのポジションが正確であるとは決して考えない方がよいでしょう。
質問に答えるためには、すべてを手作業でダブルチェックし、再スキャンする必要があるので、明日、詳しく調べます。
それがデュアル仮想化の代償です。
特にVirtualBoxはHyper-Vタイプのフルハイパーバイザーではなく、異なるユースケースに合わせたCPUシェルを持つ現在のデスクトップ OS（Windows 7もか）の上に乗っているのですから。
つまり、Windows 7/10 -> VirtualBox -> Windows 7 というように、2段階の仮想化が可能で、最初の人はVirtualBoxの目的を知らず、普通のプログラムとして見ているのです。CPUのリソース割り当て（スレッドシェジュラー）が明らかに狂っている。
そうでなければならない。Hyper-V 2016/2019 -> Windows 2016/2019
いや、俺のCentOSには仮想化装置が回ってるんだけどね。しかし、私はこの対話を続ける能力がない。