«Напоминаю также, что торговая система не является системой точного времени,
детальные исследования по latency мы проводим только в случае обоснованных подозрений
в наличии проблемы на нашей стороне, при этом обязательным условием (не наша прихоть,
просто без этих данных реальный аудит маловозможен) является предоставление детальных логов софта,
снятого дампа трафика на момент проблемы и детального описания методики замеров latency на стороне клиента.»
ログを見る限りでは、同じ印象を受けます。50msまで上がり、その後10msまで急降下します。秒の遅れが目立つ。
遅延の問題を研究するために、みんなこうやってログをあげてほしい。
ここは実際のデリバティブ市場での取引以上にバタバタしているので、解決は(もし解決したとしても)すぐには無理でしょう...。
追加
最も不満なのは、この遅延がトレード時に現れ、トレードが有益なものから不利なものになることです。
追加
もちろん、取引所も歯を見せている
ストラテジーテスターで、期限切れの注文が完全に執行されたと書かれているのですが、そうではありません。
また、「HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT);」というコマンドを呼び出しても、0が表示されます。
例えば、tisket=37のオーダーは、写真をご覧ください。
ストラテジーテスターで、期限切れの注文が完全に執行されたと書かれているのですが、そうではありません。
また、「HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT);」というコマンドを呼び出しても、0が表示されます。
例えば、tisket=37のオーダーは、写真をご覧ください。
ストラテジーテスターで、期限切れの注文が完全に執行されたと書かれているのですが、そうではありません。
また、「HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT);」というコマンドを呼び出しても、0が表示されます。
例えば、tisket=37のオーダーは、写真をご覧ください。 どこかが間違っているのでしょうか?
また、HistoryOrderGetDoubleを呼び出す 前にHistorySelectを行うのですか?
HistoryOrderGetDoubleを呼び出す 前にHistorySelectを行いますか?
はい、そうです。ループで全歴史を走らせる。オトクリティのデモ端末。はい、そして図では、すべてが実行されていることがわかります(10点満点)。
HistoryOrderSelect(ticket)を試してみる。
履歴に残るのは37次だけです
HistoryOrderSelect(ticket)を試してみてください。
履歴に残るのは37次だけです
if (HistoryOrderSelect(37))
Print(HistoryOrderGetDouble(37,ORDER_VOLUME_INITIAL),",HistoryOrderGetDouble(37, ORDER_VOLUME_CURRENT))を実行します。
書き込み 10 0.
また、HistorySelect()およびそれに関連するすべてのものを慎重にチェックし、すべてが確実に動作するようにしました。
今、改めて見てみると、期限切れのオプションはどこかでキャンセルされています :) 。 サーバーの問題で、作業中なのでしょうか?
ビルド1430
ビルド1430
そこに足りないもの