SL/TP注文の受付 - ページ 8

[fxsaber]

Andrey Khatimlianskii #:

ちなみに、そうですね、面白いです。小さなリミッターが巨大なポジションのTPと同じレベルにあり、そのTPが大きいからとリダイレクトされると、リミッターが埋まるチャンスすらないのでは？

前提が違う。ティーのキューは、すべてのティーが送信されると失効します。つまり、リミッターはすべてのテクスチャーの送信を待っているのであって、その送信の結果を待っているのではない。

リミッターの送出が遅くなるのは、リミッターの量が多いからではなく、リミッターの価格帯が多いからです。例えばmin.ロットで。

[Andrey Khatimlianskii]

fxsaber #:

前提が違う。トークンのキューは、すべてのトークンが送信された時点で失効します。つまり、リミッターはすべてのテクスチャーの送信を待っているのであって、その送信の結果を待っているのではない。

他のリミッターの送信を遅らせることができるのは、リミッターの量が多いからではなく、リミッターの価格水準が高いからである。例えば、最小ロットで。

まあ、少なくともこっちはね。全てのTPとLimitをコンスタントに実行するよりは良いと思います。

でも、キューはもちろん直した方がいいですよね。TPは定期的に制限をかけるべき。

[fxsaber]

Andrey Khatimlianskii #:

まあ、少なくともそういうことです。TAや制限を全て一貫して行うより良いと思います。

しかし、キューを修正することは、もちろん必要なことです。TAは通常のリミッターであること。

詳しくはこちらを ご覧ください。事例を交えて

[fxsaber]

fxsaber #:

詳しくはこちらを ご覧ください。事例を交えて

TP注文発動ティックが誕生した後に疑惑が！？つまり、TP注文が先に生まれ、その後に初めてTP注文が生まれる原因となったティックが生まれたのです。これは妄想にしか聞こえない。では、その写真を詳しく見ていきましょう。

台本は間違えていない、本当だ!ティックのデータベースが大きなラグで埋まって しまうということです。そして、ティックタイムが記録時間として設定されます。I.e. 誤って刻まれた時間。

というわけで、MT5の アーキテクチャ上のバグが 発見されました。

からMQ-Demoでこのバグを再現。

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define  Bid SymbolInfoDouble(_Symbol, SYMBOL_BID)
#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inTP = 10;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart()
{
  OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, Ask + inTP * _Point);

  OrderSend(_Symbol, OP_SELL, 0.1, Bid, 0, 0, Bid - inTP * _Point);
}

ポジションを決済した後、トリガーされたティックの時刻と、チェックをトリガーするはずだったティックの時刻を見ます。

このティックは、ティックを作動させたと思われるティックが現れる61ミリ秒 前に作動していることがわかります。

このバグはMQ-Demoで再現されるだけでなく、実際のアカウントにも存在しています。しかし、上記のようにMQ-Demoですぐに再現することができます。

トレードサーバーのティックデータベースは、残念ながら歪んでいます。

検索文字列：Oshibka 042.