// Script to test Millisecond Resolution via GetSystemTimeAsFileTime()#import "kernel32.dll"void GetSystemTimeAsFileTime(ulong &SystemTimeAsFileTime); // Returns the system time in 100 nsec units in a ulong
#importvoidOnStart() {
ulong startL, nowL;
GetSystemTimeAsFileTime(startL);
for (int j=0; j<1000000000; j++) {
GetSystemTimeAsFileTime(nowL);
if (nowL > startL) {
int diff = int(nowL - startL);
MessageBox(StringFormat("GetSystemTimeAsFileTime %llu -> %llu diff %d in 100 nsec units = %.1f msecs",
startL, nowL, diff, diff/10000.0), "Test Millisecond Resolution via GetSystemTimeAsFileTime");
return;
}
}
}
全てです。
ここで質問したいのは、ティックのタイムスタンプを取得することであり、GetTickCount()を使用して ティックがターミナルに到着した時（つまり、start()関数が呼ばれた時）ではない、ということです。
MarketInfo(Symbol(), MODE_TIME)は、データフィードのブローカーのサーバーから送信されたティックのタイムスタンプを返します。
参考
VS
全てです。
ここで質問したいのは、ティックのタイムスタンプを取得することであり、GetTickCount()を使用してティックがターミナルに到着した時（つまり、start()関数が呼ばれた時）ではない、ということです。
MarketInfo(Symbol(), MODE_TIME)は、データフィードのブローカーのサーバーから送信されたティックのタイムスタンプを返します。
1) GetTickCount()、ライブで動作するはずです。ヒストリカルデータでは無意味。
2) mt5_data でも、ミリ秒単位で保存されていない。ただし、Liveではno_problem。
3)どこがどうなっているのかわからない。ミリ秒単位で同じ時間なら、ミリ秒があってもしょうがないでしょう。ミリ秒単位で異なる時間なら、GetTickCount()で解決できるかもしれません。この場合、コードが1ミリ秒以内に現在のティックを処理するという意味で役に立ちます。 どの程度重要かは、何を達成しようとしているかによると思います。
皆さん、ご回答ありがとうございました。 コードベースにRogue Tick Detectorというインジケータが投稿されていました。 しかし、まだ承認されていません。 今のところこちらで 確認できます。
基本的な考え方は、現在のティックtick0は前のティックtick-1よりも遅いタイムスタンプで来る時間があることです。 しかし、その価格はもはやアクション可能なものではなくなってしまうのですが、EAや人間のトレーダーは事後的になるまでそれを知ることはできません。 このため、価格ベースのイベントが誤ってトリガーされることがありました。不正なティック検出器は、これらの偽のティックにフラグを立て、EAがそれに基づいて行動するのを防ぐことができました（次の「良い」ティックを待ちます）。
ティックのタイムスタンプを取得する現在の方法であるMarketInfo(Symbol(), MODE_TIME)は、ミリ秒のタイムスタンプを返しません。 そこで、私たちが見落としている代替手段がないかと思い、ここに相談に来ました。
不正ティック検出機能を含むEAはすべてSSDドライブ、Windows2008を搭載したニューヨークのVPSで動作し、通常ブローカーサーバから<2msの距離にあります。 HFTやハイパースカルピングはありません。
私の最初の質問の一つに戻ります。 mt4（とmt5）のプラットフォーム（それ自体）は、どのようにして「同じ時間」に入ってきたティックを適切に区別することになっているのでしょうか？
edit, 明確にしてくれてありがとうankasoftware.
私の最初の質問の一つに戻ります。 mt4（とmt5）プラットフォーム[自体]は、どのようにして「同じ時間」に入ってきたティックを適切に区別することになっているのでしょうか？
あなたのブローカーは、実際に同時に発生した複数のティックを送ってくるのですか？ それとも、カウントを2つ増やして、後のティックを送ってくるのですか？ そうだとしたら、どうやって知ることができますか？ ブローカーによってティックカウントに大きな違いがあることをご存知ですか？
はい、私は、ブローカーによってフィードが異なり、ティックカウントが大きく異なる可能性があることを認識しています。 しかし、不正なティックが特定の時間帯、主に取引が利益で決済されたときに送信されていることが偶然にも判明したのです。 クローズオールや注文のトリガーに影響を及ぼしていたので、それを検知して無視する方法を可能な限り見つけました。 一部のブローカーから、ある時点で意図的なフィード操作を疑ったこともあります。
しかし、もしかしたら、ダニの総数をカウントする、ダニ数比を持つべきかもしれません
それは多くの人々に影響を与えないかもしれませんが、私は潜在的な損害は、さらに調査を保証するのに十分だと思いました。
何を考えているのでしょうか？mt4 Volumeとどう違うのでしょうか？どのような2つの数値の比率[ カウントと?カウント]。
このテーマは非常に速く非常に混乱します。私自身は、含まれているdo - ticksについてのすべてを知っている、またmetaQuotesがそれを処理する方法、またなぜそれが誰かに非常に重要になるでしょう。私の観察をいくつか要約させてください。
1）metaQuotesは言う：あなたはミリ秒のタイムスタンプをしたい、[ 彼らはすぐにtick_dataを考え始める]、誰がこのtick_dataを保持するために起こっているブローカー？ あなたはその分以内に200ティックがあると言うことはあなたのために十分ではありませんか？OHLC+Vが十分でないからといって、200回分のデータを保存しろというのですか？
2) トレーダー1号さんのコメント： 情報の保存は必要ない、ただ古いデータを判断するためにミリ秒単位のタイムスタンプが欲しい。
3) trader number2のコメント：情報を保存してもらう必要はない、ただそれをインポートする機能を与えてくれれば、自分のデータを入手できる。
4) トレーダー3号の意見：ティックデータを保存して提供することが、なぜそんなに重要なのかわからない。最近のコンピューターはパワーもメモリも充実しているのだから、ブローカーがどこかでデータを提供してくれるに違いない。
5) ブローカーのコメント：私は、あなたに3ヶ月以上のM1データを提供するのに十分苦労しているのですが、あなたが接続したときやテストのために、私がそれだけのデータを提供する能力や意志があるとお考えですか。
6) trader number4: テストには必要ありませんし、データもライブではほんの一部で十分です。
7) metaQuotes: やはりダメですね、これではmilli_secondsを返す関数やティックを区別するインジケータなどを容易にしなければなりませんね・・・ターミナルか何かをクラッシュさせようとしているのでしょうか？
8) trader number5: Volumeは、market_depthではなく、与えられたtime_frame内のticksの数のカウントということですね :)..ティックを見逃すことがあるってこと？あなたは、ティックが失われたり、サイバー空間での遅延が発生する可能性があるということですか？tick_countはブローカーによって異なるということですか？ブローカーが保存するデータは、私が受け取ったものと同じではなかったと言うことですか？それなら、ティックについて大騒ぎするのは何なのでしょうか？
9) xxxxxxxxxxのコメント：tickはトップシークレットで、提供されるものは確かに十分なものです。
10) トレーダー番号6：提供できるもの、ティックカウントの動作、受信できるものなど、技術的な限界があります。これは、metaTraderの問題ではなく、むしろ、多くの小売プラットフォームがこの問題を経験しています。機関投資家向けのソフトウェアに目を向け、大金を払う覚悟をしてください。
Trader#3 to Trader#10: 私は同意しません。
Ubzen のコメント: もう何を言っていいのかわかりません。
Ps> Trader#7 を忘れるところだった：いいよ、自分のターミナルに来るティックを保存して、このデータを処理するために自分のインジケータなどをプログラムするよ。というのが私の解釈で、だからGetTickCount()を薦めたわけです。
Ps> Trader#7 を忘れるところだった: いいよ、ターミナルに来る自分のティックを保存して、このデータを処理するために自分のインジケータなどをプログラムするよ...ということで、GetTickCount()をお勧めした次第です。
私はここでトピックにとどまることを望んでいます :)。とはいえ、ティック ごとにミリ秒単位のタイムスタンプを送信するブローカーを想像してみてください。しかし、この情報を彼女側で保存しないようにする。一般的にブローカーに対する不信感を考えると、このブローカーは問い合わせの猛攻撃を開始することになります。しかし、今回、人々はミリ秒単位で証拠を持っていますが、ブローカーはそれに対抗するための記録を持っていない。つまり、ある意味では、tick_data｜millisecondsなどを求めることは、基本的にブローカーにtick_dataを保存するよう求め、プラットフォームがそれを容易にするよう求めているのと同じことです。
もう一つ、多くの人が行っている逆バックテストを考えてみましょう。ストラテジー_ライブを1週間ほど実行し、その1週間後に同じ結果が得られるかどうかを検証するためにバックテストを実行することをお勧めします。この人は、ミリ秒単位のタイムスタンプが生きていて、遅延やパケット欠損も生きています。もちろん、元の投稿者のように、欠落したデータを無視したり、遅延したティックを無視したりすることができます。しかし、バックテストを実行すると、正しいタイムスタンプを持つすべてのブローカーのデータがそこにあります。これは明らかに、あなたがライブで受け取ったものとは異なる結果を生成します。
だから教えてください、あなたはライブで誤解されたのか、それともBack_Testの間に誤解されているのでしょうか？
しかし、私は上記のあなたの声明に同意 します。イモ、このすべては、私が離れてすべて_一緒に分間プロセスから滞在することをリードするパラドックスのセットを作成します。プラットフォームには限界があり、私はただ受け入れ、移動する。
...
しかし、私は上記のあなたの声明に同意 します。イモは、このすべてが一連のパラドックスを作成し、私はすべて一緒に分間プロセスから遠ざかるに至ります。プラットフォームには限界があるので、私はそれを受け入れて前進するだけです。
タイマ、タイマ分解能、効率的なコードの開発
Windowsタイマーの解像度：メガワット浪費面白いリンクありがとうございます。そのおかげで、Microsecond Resolution Time Services for Windows にたどり着きました。これらのページの情報を元に、いくつかのテストを行ってみました。
Win 7 PC と Windows 2012 VPS でテストしたところ、GetTickCount() はシステムタイマーの設定に関係なく常に 15.6 ミリ秒 (64 interrupts per second) の分解能を持つのに対し、 kernel32.dll 関数の GetSystemTime() [or GetLocalTime()] や GetSystemTimeAsFileTime() を呼んでミリ秒の時間を得る際の分解能はシステムタイマー設定の影響を受け、私がテストを行った両マシンで 0.5 ミリの分解能まで下がる場合があることが判明しました。
GetTickCount()の分解能
GetTickCount()の分解能をテストするスクリプトのコードを以下に示します。
このスクリプトは、他のテストで後述するシステムタイマーの分解能の変更に関係なく、テストした両方のマシンで常に 15 または 16 (つまり 15.6) を出力します。
GetSystemTime() 分解能
さて、いよいよ面白くなってきました。以下は、GetSystemTime() の解像度をテストするスクリプトのコードです。
これは、起動したばかりのPCで、他のソフトウェアが起動していない場合、15/16ミリ秒の分解能を与えますが、PC上でChromeが起動している場合は、1ミリ秒になります!angevoyageurの2番目のリンクにあるように、Chromeはシステムタイマーを1ミリ秒の分解能に設定し、他のいくつかのソフトウェアも同様です。
システムタイマーの分解能を設定するための小さなユーティリティを2つ見つけましたので、クリーンブートしたマシンで1ミリ秒（あるいは0.5ミリ秒）の分解能を制御された方法で得ることができるようになりました。
Windowsシステムタイマーツール: http://vvvv.org/contribution/windows-system-timer-tool
タイマ分解能:http://www.lucashale.com/timer-resolution/
私はこの2つのうち、最初のWindows System Timer Toolが好きです。このツールでは、GetSystemTime()を使って確実に1ミリ秒の分解能を得ることができます。GetLocalTime()も同じように使うことができます。
上のスクリプトは、新しいMT4のコードが構造体のおかげでどれだけ良くなったかを示す例です。古いMT4では、GetSystemTime()にアクセスするために、整数配列の使用と多くの面倒なビット操作が必要でした。
GetSystemTimeAsFileTime()の分解能
最後に、Microsecond Resolution Time Services for Windowsに よると、GetSystemTimeAsFileTime()はシステム時間にアクセスするための高速な関数で、より小さくてシンプルな構造体が必要であると述べています。新しいMT4では、「構造体」が単なるulongに縮小されるため、後者は確かに当てはまります。
以下は、GetSystemTimeAsFileTiime()の解決をテストするためのスクリプトのコードです。
Windowsシステムタイマーツールを使用して、システムタイマーの分解能を0.5秒に設定すると、この小さなスクリプトは、5000（または5001）100nsecs単位＝0.5msecsの分解能を報告します。
GetSystemTimeAsFileTiime()を使用すると、よりシンプルで、より細かい解像度を表示することができます。
これは、実際に使っている写真です。
クリーンブート後。
Timer Toolでシステムタイマーの分解能を1msに設定した場合。
Timer Toolでシステムタイマーの解像度を0.5msに設定した場合。
結論MT4でミリ秒のタイミングを得るために使用する最適な関数は、上記のテストスクリプトに示すように呼び出されるGetSystemTimeAsFileTiime()で、Windows System Timer Toolなどのユーティリティを使用して目的のシステムタイマーの解像度を設定する。