В языке MQL5 предусмотрена обработка некоторых предопределенных событий. Функции для обработки этих событий должны быть определены в программе MQL5: имя функции, тип возвращаемого значения, состав параметров (если они есть) и их типы должны строго соответствовать описанию функции-обработчика события. Именно по типу возвращаемого значения и по...
コンピュータの前にいて、何も計算しなかった。CPUに何も負荷をかけていない。
19ms、SymbolInfoTickの実行は48msです。数百マイクロ秒というケースも数十件あった。でも、引き合いに出してはいないんです。
どうやら再現するためには、コンバットアドバイザーを24時間稼働させ、あとは見るだけにする必要があるようです。何が原因でこのようなラグが発生するのかを解明するのは非現実的だと私は思います。
時々、コンプはポンピングアップデートや何らかのサービス作業をしていることがあります。また、主電源電圧の変動も影響することがあります。この方法で、すべてのボットロジックがハードワイヤードされているプログラマブルネットワークカードに到達することができます :) しかし、そこでも量子場の揺らぎによる遅延が発生します。
開発者は最善を尽くしました。また、それでなくとも、ティックがMarket Watchに遅れをとっていること、またその逆であることを示すコードが、このブランチから提供されているのです。ティックの到着シーケンスがどのように壊れているか、そしておそらく他の何かです。すべてにおいて、他の状況を再現するために厄介な有効なコードが掲載されています。
SymbolInfoTick は、ブローカーのサーバーから受信したデータを送信する。サーバーが送信するものが、あなたが受け取るものです。
SymbolInfoTick()は ブロッキングモードで実行されますか、それともノンブロッキングモードで実行されますか？
例えば、whileループのボディで、接続がないとか、週末でマーケットが閉じているとか、
、ループを停止してブロックするのか、非同期に実行するのか。
マーケットウォッチがどのように遅れているか、逆にどのように遅れているか。
SymbolInfoTickが 新しいティックをキャッチし、Market Watchイベントを通じて（Market Watchの変更を待たずに）異なるAskとBidを取得する場合などですか？1年ほど前にはできなかったことです。SymbolInfoTickとCopyTickとVintageは常に同じtickを導きます。様々なOnXXX関数を通してティックを取得する場合、当然、ある関数を通して何かを取得し、別の関数を通して何かを取得することになるのですが...。
つまり、SymbolInfoTick が新しいティックをキャッチし、カップをポーリングすることで（カップの変更イベントを待たずに）異なる Ask と Bid を取得するのですか？
これです。
これです。
やはり、MarketBookGetとSymbolInfoTickではなく、OnBookEventとOnTickをテストしているのですね。この方式でテストすれば、すべてが一致するはずです。
p.s 以下の皆さんの投稿を読んでみてください。あなたも理解しているはずです。なぜOnBookEventとOnTickが 全く必要ないのですか？私の例では、Sleep(1)は1-2ミリ秒かかり、SymbloInfoTickによるリクエストとティックはマイクロ秒未満で完了します。ティックがなければ、プロセッサはすでに99.9%休んでいます。OnBookEventとOnTickを 使用するメリットは何ですか？
やはり、MarketBookGetとSymbolInfoTickではなく、OnBookEventとOnTickをテストしているのですね。この方式でテストしていれば、すべて合致しているはずです。
p.s 以下の皆さんの投稿を読んでみてください。あなたも理解しているはずです。なぜOnBookEventとOnTickが 全く必要ないのですか？私の例では、Sleep(1)は1-2ミリ秒かかり、SymbloInfoTickによるリクエストとティックはマイクロ秒未満で完了します。ティックがなければ、プロセッサはすでに99.9%休んでいます。OnBookEventとOnTickを 使用するメリットは何ですか？
外交的な気配もなく、ナンセンスなことを言っている。Sleep(1)は10分の1ミリ秒です。セオリー通りしか見えません。
OnTick のユーザーは、少し前に Terminal に到着したものではなく、新鮮なティックを見たいと思っています。ソースコードでMarketBookGetの直後にSymbolInfoTickを 記述すればよい。
開発者は、その沈黙の中で2つの問題点を完全に認めている。
外交的な気配もなく、無意味なことを言っている。Sleep(1)は十数ミリ秒です。セオリー通りしか見えません。
ユーザーは、OnTick で新鮮なティックを見たいのであって、少し前に Terminal に到着したティックを見たいわけではありません。ソースコードでMarketBookGetの直後にSymbolInfoTickを記述すればよい。
開発者は、その沈黙によって、2つの問題を完全に認めたことになる。
常にではありませんし、10分の1秒単位でもありません。簡単なスクリプトで確認
以下は私のログです。
OnTickのユーザーは、常に新鮮なティックを見ることができます。
OnBookEventのユーザーは、常に新鮮なティックを見ることができます。
しかし、OnTickで受け取ったティックとOnBookEventで受け取ったティックを比較したい場合、イベントは 並列ではなく逐次処理されるため、失望を味わうことになる。ユーザーのpivomoeさんが伝えようとしたことです
常に、どこでも10分の1ミリ秒というわけではありません。簡単なスクリプトで確認
以下は私のログです。
そして、これが私のログです。
結果
OnTickのユーザーは、常に新鮮なティックを見ることができます。
OnBookEventのユーザーは、常に新鮮なティックを見ることができます。
何もしていないマシンから1枚のチャートでEAを 実行した結果です。
異なるOn関数で対応するメソッドによって受信される同一のティックをマークする。1つのチャートではなく、6つのチャートで実行した場合、最大で数十ミリ秒のラグが発生することがあります。
しかし、OnTickで受け取ったティックとOnBookEventで受け取ったティックを比較したい場合は、イベントが 並列ではなく、順次処理 されるため、失望することになります。ユーザーpivomoeが伝えようとしたこと
ほぼ空のOnBookEvent/OnTickが、対応するほぼ空のOnTick/OnBookEventより20ミリ秒後にトリガーされる場合、それは問題ないですか?
ZS スレッドに注目している間に、ここにもリプロダクションコードが。そこでは、Market Watchでは、その前のMarket Watchの時間よりも早い時間でティックが入る。
ほぼ空のOnBookEvent/OnTickが、対応するほぼ空のOnTick/OnBookEventより20ミリ秒後にトリガーされる場合、それは問題ないですか?
EAキューはロック可能なリソースである。イベントがキューに書き込まれると、Expert Advisor は待機します（Expert Advisor が現在イベント処理中でない限り）。
Expert Advisor のイベントは、対応するチャートのイベントキューから発生し、そのイベントキューは、対応するシンボルの処理サイクルから発生します。そして、この処理のループは、イベントを自分のチャートに配信するだけでなく、他にも様々なことを行っています。
WindowsがリアルタイムOSでないことは、すでにお伝えしたとおりです。