接受SL/TP订单

Aleksey Mavrin 2020.11.25 06:29 #11

这些信息应该发给所有的MT大型HFT，只是开玩笑))廉价的代价是这样的。

Andrey Khatimlianskii 2020.11.25 15:03 #12

fxsaber:

在另一个主题中已经反复说过，即使是终端机也会因为大量的因素而放慢速度。因此，一个更加复杂的交易服务器必然会变得更加缓慢。我仍然希望算法优化仍然是可能的。即使是5毫秒的滞后，也已经非常糟糕了。怎么说呢，几百毫秒的时间。

模拟账户的情况不是很有趣（我可以在那里调试任何插件，测试新的硬件，等等）。

而我发现在真实账户上最多只有17毫秒（我不是说它不长，只是不能与30秒相比）。

因此，对级联服务器设置的怀疑。

fxsaber 2020.11.25 15:30 #13

Andrey Khatimlianskii:

在演示中，这不是很有趣（你可以在那里调试任何插件，测试新的硬件，...）。

而在真实账户上，我发现最多17毫秒（我不是说它不够，它只是不能与30秒相比）。

不幸的是，他们没有显示他们检查了多少个订单。

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

接受SL/TP订单

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

因此，对级联服务器设置的怀疑。

经纪人确认了这个问题，并设法找到了它，并进行了修复（将在周末后提供）。但是很难说这是否是由于MT5的原因。

但在这种情况下，向MT5的方向扔石头肯定是可以做到的。

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

接受SL/TP订单

fxsaber, 2020.11.25 00:47

我不知道当我在终端上交易时该怎么做，但我在交易服务器上有一个非常低的选择，我不知道在终端上交易时该怎么做。也就是用一个非常低的ping和一个交易服务器的交易账户。

终端和服务器是在同一台机器上。零负荷。一个新鲜的想法得到了这样的提醒。

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED

服务器日志。

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]

在服务器上接受-点击。

完整的脚本数据确认有问题。在零负载的服务器内部，有一个4ms的滞后。

fxsaber 2020.11.25 15:46 #14

Andrei Trukhanovich:

fxsaber的另一个大脑爆炸。

当你意识到你已经浪费了多少时间时，感觉特别糟糕。而且，没有人会为你做这件事。

Enrique Dangeroux 2020.11.25 16:05 #15

这似乎真的是服务器上的一个问题。这是一个模拟MT5账户

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

在同一经纪人的真实账户上，该脚本返回的结果为零。该账户上有3000多笔交易。

fxsaber 2020.11.25 16:10 #16

Enrique Dangeroux:

在同一个经纪商的真实账户上，该脚本返回的结果为零。该账户有3000多笔交易。

这是很可疑的。我在我的账户上没有发现任何滞后现象。

Enrique Dangeroux 2020.11.25 16:20 #17

我不确定这是否有关系。但我得到了很多。

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

当位置改变时触发Take的错误。因此，"拿 "被触发，偏转了几次，然后挂掉了，我把tp改为零，以备份和崩溃。

在我改变它之前，我检查它

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

这样，位置就不会被冻结。

Enrique Dangeroux 2020.11.25 16:21 #18

fxsaber :

这是很可疑的。在我的账户中，没有一处发现缺乏滞后性。

我也是这么想的，但进一步的调查显示，光是采取关闭措施的就有大约100个。

因此，对一个小的样本量。

fxsaber 2020.11.25 16:27 #19

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

接受SL/TP订单

Enrique Dangeroux, 2020.11.25 17:20

不知道这是否与此有关。但我得到了很多。

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

我的整个日志中也有这样的信息。也许在周末之后，情况会有所改变。

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

接受SL/TP订单

fxsaber, 2020.11.25 16:30

经纪人确认了这个问题，并设法找到并解决了这个问题（将在周末后提供）。但是很难说这是否是由于MT5的原因。

fxsaber 2020.11.26 07:42 #20

让我们以示意图的方式考虑一下交易大厅的一些算法。为简单起见，我们将假设只有一个LP（流动性提供者）。

限价单。

来自LP的价格满足了交易大厅限价单的价格。
Gateway将此限价单发送给LP，并规定了较短的到期时间。
如果Gateway收到了部分限制量的重定向，Gateway将对剩余的量重复第1点的一切，以防来自LP的tick在限制处理期间发生变化。

一个好的网关（采用上述算法）在执行限制器时是独立于交易平台的具体情况的。

该算法几乎是循环的，与平台无关。LP垃圾邮件保护包含在第3点。

未平仓合约的TP级别。

来自LP的嘀嗒声
该价格作为一个新的刻度线被发送到MT5。
如果头寸没有被封锁，并且新的勾股价格符合TP水平，MT5会创建一个TP订单。
网关看到一个TP订单的诞生，锁定头寸并执行限价订单算法的第2步。
如果它收到一个重新劫持的订单，那么MT5会将TP订单以拒绝状态发送到历史。该位置已被解锁。

该算法不是循环的，并且取决于平台。有防止垃圾邮件的LP。

这种算法除了Gateway-MT5的通信成本外，还有两个缺点。

在这个主题中已经表明，MT5的TP订单（见第3点）的诞生有一个滞后。因此，TP订单能够执行的概率低于没有滞后的情况。
在MT5中，没有新的tick就不能创建TP订单。这 意味着，如果收到一个重定向，网关将不会做任何事情，直到一个新的tick到达MT5，满足TP水平。而试图执行TP级的宝贵时间也因此而丧失。这也恶化了FillRate的情况。

改进。

开仓的TP级算法中的智能网关有第6页。

6.如果在重定向期间从LP收到了一个新的tick，其实际值将作为一个新的tick重新发送到MT5 - 转到步骤2。

这个额外的算法点仍然包含对LP垃圾邮件的保护，但它欺骗MT5执行第3点。而且没有损失宝贵的时间来等待新的tick。

现实。

从这两个算法（即使在第二个算法的第6点的情况下），这就可以看出。

MT5限价单的FillRate比TP级开仓的形式的等价物要高。这 就是为什么在MT5-Hedge的翻转过程中，我们可能经常遇到限价单被执行，但其对应的TP却没有被执行的情况。在这种情况下，将进行CloseBy，并以相应的数量重新执行限价订单。

结论。

为了提高MT5的FillRate，将未结头寸的TP水平转移到MT5限价单中。

接受SL/TP订单 - 页 2

限价单。

未平仓合约的TP级别。

改进。

现实。

结论。