接受SL/TP订单 - 页 2 12345678 新评论 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限价单中。 12345678 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
在另一个主题中已经反复说过,即使是终端机也会因为大量的因素而放慢速度。因此,一个更加复杂的交易服务器必然会变得更加缓慢。我仍然希望算法优化仍然是可能的。即使是5毫秒的滞后,也已经非常糟糕了。怎么说呢,几百毫秒的时间。
模拟账户的情况不是很有趣(我可以在那里调试任何插件,测试新的硬件,等等)。
而我发现在真实账户上最多只有17毫秒(我不是说它不长,只是不能与30秒相比)。
因此,对级联服务器设置的怀疑。
在演示中,这不是很有趣(你可以在那里调试任何插件,测试新的硬件,...)。
而在真实账户上,我发现最多17毫秒(我不是说它不够,它只是不能与30秒相比)。
不幸的是,他们没有显示他们检查了多少个订单。
关于交易、自动交易系统和测试交易策略的论坛
接受SL/TP订单
fxsaber, 2020.11.25 01:23
因此,对级联服务器设置的怀疑。
经纪人确认了这个问题,并设法找到了它,并进行了修复(将在周末后提供)。但是很难说这是否是由于MT5的原因。
但在这种情况下,向MT5的方向扔石头肯定是可以做到的。
关于交易、自动交易系统和策略测试的论坛
接受SL/TP订单
fxsaber, 2020.11.25 00:47
我不知道当我在终端上交易时该怎么做,但我在交易服务器上有一个非常低的选择,我不知道在终端上交易时该怎么做。也就是用一个非常低的ping和一个交易服务器的交易账户。
终端和服务器是在同一台机器上。零负荷。一个新鲜的想法得到了这样的提醒。
服务器日志。
在服务器上接受-点击。
完整的脚本数据确认有问题。在零负载的服务器内部,有一个4ms的滞后。
fxsaber的另一个大脑爆炸。
这似乎真的是服务器上的一个问题。这是一个模拟MT5账户
在同一经纪人的真实账户 上,该脚本返回的结果为零。该账户上有3000多笔交易。
在同一个经纪商的真实账户 上,该脚本返回的结果为零。该账户有3000多笔交易。
这是很可疑的。我在我的账户上没有发现任何滞后现象。
我不确定这是否有关系。但我得到了很多。
当位置改变 时触发Take的错误。因此,"拿 "被触发,偏转了几次,然后挂掉了,我把tp改为零,以备份和崩溃。
在我改变它之前,我检查它
这样,位置就不会被冻结。
这是很可疑的。在我的账户中,没有一处发现缺乏滞后性。
我也是这么想的,但进一步的调查显示,光是采取关闭措施的就有大约100个。
因此,对一个小的样本量。
关于交易、自动交易系统和测试交易策略的论坛
接受SL/TP订单
Enrique Dangeroux, 2020.11.25 17:20
不知道这是否与此有关。但我得到了很多。
我的整个日志中也有这样的信息。也许在周末之后,情况会有所改变。
关于交易、自动交易系统和测试交易策略的论坛
接受SL/TP订单
fxsaber, 2020.11.25 16:30
经纪人确认了这个问题,并设法找到并解决了这个问题(将在周末后提供)。但是很难说这是否是由于MT5的原因。
让我们以示意图的方式考虑一下交易大厅的一些算法。为简单起见,我们将假设只有一个LP(流动性提供者)。
限价单。
一个好的网关(采用上述算法)在执行限制器时是独立于交易平台的具体情况的。
该算法几乎是循环的,与平台无关。LP垃圾邮件保护包含在第3点。
未平仓合约的TP级别。
该算法不是循环的,并且取决于平台。有防止垃圾邮件的LP。
这种算法除了Gateway-MT5的通信成本外,还有两个缺点。
改进。
开仓 的TP级算法中的智能网关有第6页。
这个额外的算法点仍然包含对LP垃圾邮件的保护,但它欺骗MT5执行第3点。 而且没有损失宝贵的时间来等待新的tick。
现实。
从这两个算法(即使在第二个算法的第6点的情况下),这就可以看出。
MT5限价单的FillRate比TP级开仓的形式的等价物要高。这 就是为什么在MT5-Hedge的翻转过程中,我们可能经常遇到限价单被执行,但其对应的TP却没有被执行的情况。在这种情况下,将进行CloseBy,并以相应的数量重新执行限价订单。
结论。
为了提高MT5的FillRate,将未结头寸的TP水平转移到MT5限价单中。