接受SL/TP订单 - 页 8

[fxsaber]

Andrey Khatimlianskii #:

顺便说一句，是的，这很有趣。如果一个小的限制器与一个巨大的位置的TP在同一水平上，而这个TP因为大而被重定向，限制器甚至没有机会被填补？

错误的假设。当所有茶叶被送出时，茶叶队列就会失效。也就是说，限幅器在等待所有泰克的发送，而不是等待发送的结果。

不是大量的限幅器会减慢其他限幅器的发送速度，而是大量的限幅器在限幅器的价格水平。例如，有一个最小地段。

[Andrey Khatimlianskii]

fxsaber #:

错误的假设。当所有的令牌都被发送后，令牌的队列就会失效。也就是说，限制者在等待所有的泰克被发送，而不是等待发送的结果。

不是大量的限幅器会减慢其他限幅器的发送速度，而是大量的限幅器在限幅器的价格水平。例如，以最小批量为例。

嗯，至少是这样。这比一贯执行所有TP和Limits要好。

但你应该修复队列，当然了。TP应该是一个常规的限制。

[fxsaber]

Andrey Khatimlianskii #:

嗯，至少是这样的。这比让所有的TA和限制持续执行要好。

但修复队列，当然是必要的。TA应该是一个普通的限制器。

这里 有关于这个问题的更多细节。有例子。

[fxsaber]

fxsaber #:

这里 有关于这个问题的更多细节。有例子。

据称，TP订单激活的嘀嗒声是在TP订单诞生后才出现的!也就是说，首先诞生的是TP订单，然后才是导致TP订单诞生的tick。这听起来是一种妄想。因此，让我们详细看一下图片。

剧本没有犯错，这是真的！"。这意味着蜱虫的数据库充满了巨大的 滞后性。而滴答声的时间被设定为记录时间。即错误的滴答时间。

所以发现了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);
}

平仓后，我们看一下被触发的tick的时间和应该触发检查的tick的时间。

我们看到，在所谓激活它的嘀嗒声出现之前，该嘀嗒声已经触发了61毫秒。

这个错误不仅在MQ-Demo中重现：它甚至存在于真实账户中。但在MQ-Demo上可以立即重现，如上图所示。

不幸的是，交易服务器上的tick数据库是扭曲的。

搜索字符串：Oshibka 042。