РЕКОРДная Разница между временем последенго тика по ВСЕМ символам Минус только, что полученный новый тик по символу 494013 милесекундa.
CR 018:51:47.334 ProverkaAktyalnostiTikov (ALRS,H1) Получен НОВЫЙ тик по символу SNGR-3.19 time_msc= 2019.03.1818:41:47.988
HN 018:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) ХОТЯ до этого был получeн тик ARMD time_msc 2019.03.1818:50:02.001
18:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) Локальное время получения нового тика по символу. 2019.03.1818:51:47.33418:51:47.335 ProverkaAktyalnostiTikov (ALRS,H1) Предпоследние Локальное время попытки получить новый тик по символу 2019.03.1818:41:47.204
コメント付きのソースコードもあります。
見てみたい気もするけど?それとも、私が理解していないことがあるのでしょうか?
しました。コードがなくてもアイデアが浮かんだなぜ私にアドバイスしてくれるのか理解できない。
最も流動性の高い金融商品をMarket Watchに追加する必要があります。
そして、これらの楽器のレイヤーを追加します。
そして、OnBookEvent()がトリガーしたときに、1ティック(最後)をコピーして、すぐにローカルタイムを取って比較することになります。
どのように優れているのですか?
拝見させていただきました。コードがなくてもアイデアが浮かんだなぜ私にアドバイスしてくれるのか理解できない。
なぜ、あなたの方法が優れているのですか?
なぜなら、それが正しいものだからです
ローカルタイムではなく、サーバータイムを間違えました。
1.ダニはパケットで端末にやってきます。
2.後続の各パケットには、前のパケットで「スタック」されていない、前のパケットと同じ時刻を持つティックが含まれている場合があります。
3.OnBookEvent()は、任意のティック(価格や数量の変化)が到着したとき、つまりティックごとに 起動されます。(タイマーを作動させる - すでに悪い)。
4.全く必要ないローカルコンピュータの時間を 使っている!?
実際に取引に必要なものはこちら(取引時間帯をご確認ください。)
によって追加されました。
もし、ミリ秒単位の精度が必要なら、この
追加
しかし、これだけでは望ましい結果(取引時間の境界)を得ることはできません。
取引 セッションに刻みがない場合もあり、時間は止まりません。
誰かが保留中の注文を削除し、ティッカーが変更されたとします。
信号があるが、「古い」相関がある(時間が現在時刻でない)。
端末は正確なサーバー時刻をブロードキャスト しません。
あなたは私を理解していない。最初からやりましょう。
1) プログラムでTimeCurrent() を呼び出し、Market Watchで選択したシンボルの1つの最後の引用符の到着時刻を 取得します。
18:00:00とする。
2) 次のコマンドで、最後のSBERティックの時刻を取得します。
ありのままで 17:58:00
3) 少し時間が経過した後、再度SBERで最後のティックの時間を要求する。
17:59:00とする
質問:18:00:00にTimeCurrent()で17:59:00の時刻を知らなくても大丈夫だと思いますか?
あなたは私を理解していない。最初からやりましょう。
1) プログラムでTimeCurrent() を呼び出し、Market Watchで選択したシンボルの1つの最後の引用符の到着時刻を 取得します。
18:00:00とする。
2) 次のコマンドで、最後のSBERティックの時刻を取得します。
ありのままで 17:58:00
3) 少し時間が経過した後、再度SBERで最後のティックの時間を要求する。
17:59:00とする
注意事項:17:59:00のTimeCurrent()で18:00:00を意識しなくてもいいと思いますか?
引用したコードでは、すべてのティックを考慮することができます(問題ありません)。
最後のコードはTineCurrent()ではなく、TimeTradeServer()を使用しています - 今回は必要なだけ です。
を1日の精度でチェックし、それだけでOK!
最初からやりましょう。
一般的に、何をしたいのか、何を調べたいのか。
なぜ、ティックタイムとローカルタイムを比較するようになったのですか?
本来の目的とは?
では、この問題が実際にどのように見えるかを紹介しよう。Expert Advisorを 完全に再設計 しました。OnBookEventだけでなく、OnTimerでも新しいtickをキャッチできるようにした。
Market Watchには45個のシンボルがあります。そのほとんどが液体ではありません。
OnBookEventで新しいティックをキャッチした結果がこちらです。
例えば、シンボルSNGR-3.19の 新しいティックがTimeCurrentで 18:50 に、時刻が18:41に 捕捉されました。
それから、現時点でのローカルコンピュータの時刻の測定もあります。
1) 新しいティックを取得する。つまり、CopyTick (設定によってはSymbolInfo)を最後に呼び出した時点。
2)ラストコールの瞬間。
つまりこの場合は、get new関数が10分間呼ばれなかっただけで、問題が発生したわけです...。SNGR-3.19の OnBookEventイベントが10分間生成さ れなかったからです。
端末がイベントキューに入れ、何かの拍子にキューから消えてしまったのかもしれません。 OnTimerではこのようなエラーはありません。はい、20秒程度の遅延が発生する場合があります。
本来の目的は何ですか?
なぜ、ティータイムを現地 時間と比較する必要があるのですか?
本来の目的は何ですか?
なぜ、ティックタイムとローカルタイムを比較する必要があるのですか?
サーバーでティックが発生してからターミナルに到着するまでの最大遅延時間を知りたいのですが。そして、この時間を最短にする方法を知りたいのです。
この知識は、私自身のテスターを書く際に活用できます。開発者に遅延時間を長くするよう依頼することもできます。
TimeCurrent() - シンボルによる最後のティックの時間は、遅延時間より小さくなるので、使用することができます。最初のバージョンでローカル タイムを使用することは、良いアイデアではありませんでした。
サーバーでティックが発生してからターミナルに届くまでの最大遅延時間を知りたいのですが。そして、この時間をいかに最短にするか。
この知識は、私自身のテスターを書くときに使うことができます。そして、もっと長い遅延で開発者を困惑させることもできるようになるかもしれませんね。
なるほど。続けて...私抜きで。
そして、その他のフォーラムの皆様へ
注意事項:時刻が17:59:00のTimeCurrent()で18:00:00の刻みを意識しないのは普通だと思いますか?
この質問はムダだと思う。ティックシークエンスは少なくとも以下の条件を満たすようにしたい。
1.シーケンシャルであること、すなわち、後続の各ティックが≧前のティックの時間であること。
2.実在性。つまり,最後に到着したティックの時刻は,できるだけ現在に近い時刻になるようにします。
問題は2点目にあるようです。
2の論点は、サーバーでティックが発生してから自分が受け取るまでの時間(ラグ)を最小にし、他の人より早く処理し、売買の判断をしたい。しかし!ラグがすべての入札者に同じであれば、(私が理解する限り)問題はありません。つまり、ブローカーのサーバーに問題があっても、誰もが平等な立場で利用できるのです。もし誰かが17時59分01秒にティックの情報を得たのに、私が18時になっても得られなかったとしたら、これは大きな問題です。
そして、ここで質問です。何が問題なのか(あるのか)?ティックを(皆に)長時間与えないブローカーのサーバーや、長時間受け取らないMT5で。