接受SL/TP订单 - 页 4

新评论
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 仍然是当前的一个问题

我最后一次检查时，这个问题在上述经纪人身上得到了解决。

 

亲爱的开发者，请回答以下关于架构的问题。这些信息是战斗申请所需要的。没有索赔。


有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？

对于这个问题，我有几个答案。

  1. 在地段上。
  2. 关于票号。
  3. 从最后修改的开盘价 来看。
  4. 从订单的最后一次修改开始（例如，在限价订单中更新了拿货水平）。

如果我理解正确，那么在修改开盘价后，限制器会被适当地建立在服务器所有限制器的列表表中，并按开盘价排序。那么问题的答案就归结为，它是嵌入在价格相同的订单列表的开头还是在最后？


同样的问题不是关于限制，而是关于代币。触发相同拍摄的顺序取决于什么？是身份证的位置还是别的什么？


让我解释一下这在战斗中会有什么帮助。例如，我在同一水平上有两个限制器（或位置发球器），但手数不同。如果限价器（tee）的执行取决于最后的修改，那么我可以通过增加手数来修改限价器来提高FillRate。


也许，只有编写了相应MT5服务器部分实现的人知道这个问题的答案。

 
Andrei Trukhanovich:

与经纪人一起工作，找到瓶颈

这是什么？"蜜蜂与蜂蜜 "的关系？）
 
fxsaber:

有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？

对于这个问题，我有几个答案。

  1. 在地段上。
  2. 关于票号。
  3. 从最后修改的开盘价 来看。
  4. 从订单的最后一次修改开始（例如，在限价时更新了拿货水平）。

我认为变体4是在第四个中使用的。也就是说，任何修改都会把订单移到相应价格水平的队列末端。

 
secret:
这就像，蜜蜂与蜂蜜的关系？)

在这个特定的时刻，在这个特定的情况下，它是互利的，而且已经做了。 一个罕见的巧合。

 

MT5中的TP订单很了不起，你可以调查FillRate（订单的哪一部分被填补）。

对数以万计的此类订单的分析表明，FillRate在很大程度上取决于符号。如果一揽子TP订单同时被触发，那么FillRate将随着一揽子订单数量的增加而减少。

其他具体的细微差别也被揭示出来。但这是已经与经纪人讨论过的。


提高FillRate的秘诀：将所有相同的点位和限价器合并为一个共同的MT5限价器。


然而，这些数据只是这个话题的一个补充。独立于经纪商的问题是，MT5的ticks滞后，因此接受挂单（包括SL/TP水平）也滞后。


而在重定向后，MT5每次都会等待下一个tick来检查价格是否满足TP水平（或限制）。这可能需要几秒钟的时间。而且，检查应该总是在重排（或部分填充）后立即进行。

附加的文件：
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick是在tick被写入交易服务器的几毫秒后触发的。

// Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10;  // EMA-period
input int inAmount = 100; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

  MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


  return((StructToTime(time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0;
int MaxValue = 0;
int MinValue = INT_MAX;
int Amount = 0;

void OnTick()
{
  static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

  MqlTick Tick;
  
  const long time = TimeLocalMsc(); // Локальное время в миллисекундах

  if (SymbolInfoTick(_Symbol, Tick))
  {
    const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax(Value, MaxValue); // Максимальное значение.
    MinValue = MathMin(Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
    if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
    #define  TOSTRING(A) #A + " = " + (string)(A) + "\n"      
      Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST)));
      
      ExpertRemove();
    }
  }
}


结果。

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger(TERMINAL_PING_LAST) = 42


处理了100只蜱虫。服务器和蜱虫终端之间的到达滞后从1到8毫秒不等。平均为4毫秒多一点。这正好等于TP订单触发的滞后，这也是这个分支的起点。


滞后本身是在MT5服务器内部。服务器->终端通道与此无关。


恳请开发商消除这种滞后。现在，在零ping的情况下，我们有一个持续的延迟ticks，不仅传入终端，而且传入服务器。特别是，命令接受。


ZS 对于那些通过套利来剥离厨房经纪人的人来说，这种内置的滞后性就像来自天堂的法力。也就是说，经纪人会产生大量的额外风险。

 
你是在哪个服务器上检查的？

你用什么工具和什么网关/数据链来形成初始数据？

如果时间是由报价提供商在其远程端（如交易所网关）生成的，而不是MT5服务器本身，那么可能会有一个缺口。

你可以忘记哪些背景程序，例如有几万和几十万个平行交易 的压力测试？
 

Renat Fatkhullin:
На каком сервере проверяли?

在许多服务器上进行了检查。包括MQ-Demo。

关于交易、自动交易系统和交易策略测试的论坛

接受SL/TP订单

fxsaber, 2020.11.25 00:47

在MQ-Demo上运行的结果。

Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439
Calculation time = 00:00:11.328, Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205
Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0

Orders (2) before 726444166 with PositionID = 725926764:
------------------------
Checked Orders = 0
------------------------


该脚本声称找到了一个TP订单和一个触发其产生的tick（文本中用颜色突出显示）。看起来，如果价格已经达到交易服务器上未平仓头寸的TP水平（特别是在模拟交易中），相应的TP订单应该立即创建（不一定执行）。然而，在这种情况下，它不是立即发生的，而是在357毫秒后发生的。


在哪个仪器和哪个网关/数据链上形成了初始数据？

我检查了外汇工具、RannForex-Server、AMTS-gateway。其他配置需要澄清。

如果时间是由报价提供者在其远程侧（例如，交易所网关）形成的，而不是MT5服务器本身，那么差距可以是。

我相信，MT5服务器是在一台零ping的机器上形成的。但需要澄清的是，100%的保证。然而，上述情况表明，即使在你的服务器上也存在这个问题。

 
fxsaber:

在调查TP订单执行时，我注意到一些TP订单的创建与接受它们的点位有很大的滞后。

汇报显示，这种情况不仅在不同的经纪商上重复出现，而且在与交易服务器在同一台机器上的终端上进行交易时也是如此。也就是用一个非常低的ping和一个交易服务器的交易账户。

我鼓励你们分享你们账户的结果。帮助改进MT5!

你 "忘记 "了一个非常小的细节--你检查了58,000个订单，只发现了一个在300毫秒时出现过冲的案例。而在这些检查中，你应该清楚地关注这一点（58000中的1）。

就像之前的百万美元支票一样，你也是在寻找单一的异常点，并假装这是正常行为。


我们检查了服务器的日志，我们可以看到，我们的虚拟化与MetaQuotes-Demo服务器在那几秒钟内（在2020.09.30 19:07为4秒）身体不适，因为有大约15百万的账户和大约2百万的开仓，同时，在邻近的虚拟服务器和管理程序上也发生了一些事情。

在任何情况下，我们都会进一步研究，尽管任何系统中都有单个离群值。

12345678
新评论