堡垒。执法问题 - 页 79 1...727374757677787980818283848586...156 新评论 Renat Fatkhullin 2016.10.10 21:10 #781 处理交易中 的低延迟过程时的一般想法。当你到了每轮10毫秒及以下的数值时，你几乎无法保证延迟的稳定性。如果你有一堆网络在你面前，延迟稳定性是一个礼物，而不是一个保证。你无法控制你的同伴的网络以及他们的带宽和延迟。要获得保证，你必须亲自从网络中删除所有的中间商。以保证，你必须投资于你的硬件（带宽、计算机、路由器），并控制最大的路径。你必须是一个怪胎和一个完美主义者。 作为技术专家的经纪人和系统显然正在努力改善他们的技术基础设施并进行投资。但不幸的是，并非每个人都在这样做。 prostotrader 2016.10.10 21:10 #782 Renat Fatkhullin:终端显示的是你的终端注册/接收信号的本地时间，而不是远端每个执行步骤的确切时间。在这种情况下，你在同一时间收到所有的回应（包括来自MT5服务器的确认和在交易所下单的确认）029。由于你们之间有许多网络，因此不能保证任何数据包都能在最短的ping时间内即时传递给你。网络中的小堵塞或网络带宽的缺乏（如在经纪人处）将导致数据包的积累，然后分批交付。这就是为什么如果网络有任何问题，你无法计算不同阶段的时间。在一个理想的网络中，靠近经纪人的服务器，人们仍然可以依靠一些最小延迟的保证，计算中间步骤的时间。 回答 "我有一个完美的网络，不能抱怨 "是不合适的。因为我们谈论的是完全不同的时间，这在正常情况下是人类无法感知的。即如这里。2016.10.10 10:00:05.148 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 2016.10.10 10:00:05.148 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 2016.10.10 10:00:05.154 Trades 'xxxxx': accepted buy limit 5.00 RTS-3.17 at 98850 2016.10.10 10:00:05.154 Trades 'xxxxx': accepted sell limit 5.00 RTS-3.17 at 99780 2016.10.10 10:00:05.155 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in 6.904 ms 2016.10.10 10:00:05.156 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in 7.850 ms你为什么不做一个简单的日志，比如说交易服务器收到一个订单--交易服务器时间交易服务器给了交易所一个订单--交易服务器时间交易服务器收到交易所的回应--交易服务器的时间。然后你就会一劳永逸地结束这个长期的话题。已添加。并发送这些时间（所有三个），而不是接受和放置 执行的 时间 Renat Fatkhullin 2016.10.10 21:17 #783 也许我们将来会这样做。 fxsaber 2016.10.10 21:42 #784 Renat Fatkhullin:处理交易中 的低延迟过程时的一般想法。 这些问题似乎都是关于几百或几千毫秒的。 Renat Fatkhullin 2016.10.10 22:05 #785 fxsaber: 这些问题似乎是关于数百和数千毫秒的。在实践中，在建立了良好的基础设施，并享受每轮3-4毫秒的执行与精心组装的流动性证明者，作为一个成熟的经纪人，当人们在投入生产后看到周期性的700-1500毫秒的峰值时，会感到目瞪口呆。而完美系统的建设者们必须接受它并进行调整。所以这就是现实：无法保证最低延迟的稳定性。 特别是在一个有这么多中间阶段的环境中。 fxsaber 2016.10.10 22:08 #786 Renat Fatkhullin: 你想检查一下吗？ 关于交易、自动交易系统和测试交易策略的论坛 堡垒。关于执行的问题 fxsaber, 2016.10.10 11:38 这里有一个很好的功能，可以让开发者重现刹车的效果!现在不可能说 "我们看不到刹车 "了。开发人员应该在会话开启时开始放置限制请求并监控执行时间。如果他们看到速度慢，他们将在当地处理。遗憾的是，目前的情况令人沮丧。 在你的基础设施上。通过张贴公开市场第一分钟的日志？ prostotrader 2016.10.10 22:16 #787 Renat Fatkhullin:在实践中，在建立了良好的基础设施，并享受每轮3-4毫秒的执行与精心组装的流动性挑衅者，作为一个成熟的经纪人，人们在投入生产后看到周期性的700-1500毫秒的峰值时，会呆呆地坐在地板上。而完美系统的建设者们必须接受它并进行调整。所以这就是现实：无法保证最低延迟的稳定性。 特别是在一个有这么多中间阶段的环境中。对不起，Renat，但这不可能是网络延迟。2016.09.21 03:31:10.568 Terminal Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'') 2016.09.21 17:30:00.156 Trades 'xxxxx': modify order #44620664 buy limit 5.00 ROSN-3.17 at 36438 sl: 0 tp: 0 -> 36470, sl: 0 tp: 0 placed for execution in 19.086 ms 2016.09.21 17:30:00.157 Trades 'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in 19.185 ms 2016.09.21 17:30:00.160 Trades 'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667) 2016.09.21 17:30:01.064 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market 2016.09.21 17:30:02.004 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 2016.09.21 17:30:04.827 Trades 'xxxxx': accepted exchange sell 5.00 BR-11.16 at market 2016.09.21 17:30:04.827 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in 3764.451 ms 2016.09.21 17:30:04.829 Trades 'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682) 2016.09.21 17:30:05.799 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 2016.09.21 17:30:07.929 Trades 'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 2016.09.21 17:30:07.929 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in 5926.927 ms 2016.09.21 17:30:08.738 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 2016.09.21 17:30:08.775 Trades 'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 2016.09.21 17:30:08.776 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in 2977.588 ms 2016.09.21 17:30:09.585 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 2016.09.21 17:30:09.590 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 placed for execution in 852.561 ms 2016.09.21 17:30:09.597 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 2016.09.21 17:30:09.637 Trades 'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 2016.09.21 17:30:09.638 Trades 'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 placed for execution in 40.658 ms 2016.09.21 17:30:10.053 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 2016.09.21 17:30:10.075 Trades 'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 2016.09.21 17:30:10.079 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in 25.974 ms 2016.09.21 17:30:44.537 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 2016.09.21 17:30:44.669 Trades 'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.04 2016.09.21 17:30:44.669 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in 132.352 ms 2016.09.21 17:30:45.165 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 2016.09.21 17:30:45.179 Trades 'xxxxx': accepted sell limit 10.00 Si-6.17 at 70449 2016.09.21 17:30:45.180 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in 14.720 ms Renat Fatkhullin 2016.10.10 22:19 #788 fxsaber: 你就不能检查一下吗？ 在你的基础设施上。通过张贴公开市场第一分钟的日志？如果我们几乎无法控制任何东西，那还有什么可检查的呢。他们已经在市场开幕式上展示了具有规范证明的测试。但显然，这是一个一物降一物的案例。我在上面已经说过几次，延迟的稳定性是无法保证的。如果我们是一个经纪人，那将是另一回事--我们不会吝啬最有效的基础设施，并优化最大数量的路线。 Renat Fatkhullin 2016.10.10 22:20 #789 prostotrader:对不起，Renat，但这不可能是网络延迟。你只考虑到了你的网络延迟。你做得很好。而离你几步之遥，一切都很好。问题出在其他地方。请阅读上述所有内容。也许还能读懂字里行间的意思。 fxsaber 2016.10.10 22:27 #790 prostotrader:对不起，Renat，但这不可能是网络延迟。 妈的，有谁能告诉我，在其他平台上是否会发生这种多秒提交订单的无稽之谈？ 1...727374757677787980818283848586...156 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
处理交易中 的低延迟过程时的一般想法。
作为技术专家的经纪人和系统显然正在努力改善他们的技术基础设施并进行投资。但不幸的是，并非每个人都在这样做。
终端显示的是你的终端注册/接收信号的本地时间，而不是远端每个执行步骤的确切时间。
在这种情况下，你在同一时间收到所有的回应（包括来自MT5服务器的确认和在交易所下单的确认）029。由于你们之间有许多网络，因此不能保证任何数据包都能在最短的ping时间内即时传递给你。网络中的小堵塞或网络带宽的缺乏（如在经纪人处）将导致数据包的积累，然后分批交付。
这就是为什么如果网络有任何问题，你无法计算不同阶段的时间。在一个理想的网络中，靠近经纪人的服务器，人们仍然可以依靠一些最小延迟的保证，计算中间步骤的时间。
回答 "我有一个完美的网络，不能抱怨 "是不合适的。因为我们谈论的是完全不同的时间，这在正常情况下是人类无法感知的。
即如这里。
你为什么不做一个简单的日志，比如说
交易服务器收到一个订单--交易服务器时间
交易服务器给了交易所一个订单--交易服务器时间
交易服务器收到交易所的回应--交易服务器的时间。
然后你就会一劳永逸地结束这个长期的话题。
已添加。
并发送这些时间（所有三个），而不是接受和放置 执行的 时间
处理交易中 的低延迟过程时的一般想法。
这些问题似乎是关于数百和数千毫秒的。
在实践中，在建立了良好的基础设施，并享受每轮3-4毫秒的执行与精心组装的流动性证明者，作为一个成熟的经纪人，当人们在投入生产后看到周期性的700-1500毫秒的峰值时，会感到目瞪口呆。而完美系统的建设者们必须接受它并进行调整。
所以这就是现实：无法保证最低延迟的稳定性。
特别是在一个有这么多中间阶段的环境中。
关于交易、自动交易系统和测试交易策略的论坛
堡垒。关于执行的问题
fxsaber, 2016.10.10 11:38
这里有一个很好的功能，可以让开发者重现刹车的效果!
现在不可能说 "我们看不到刹车 "了。
开发人员应该在会话开启时开始放置限制请求并监控执行时间。如果他们看到速度慢，他们将在当地处理。
遗憾的是，目前的情况令人沮丧。
在实践中，在建立了良好的基础设施，并享受每轮3-4毫秒的执行与精心组装的流动性挑衅者，作为一个成熟的经纪人，人们在投入生产后看到周期性的700-1500毫秒的峰值时，会呆呆地坐在地板上。而完美系统的建设者们必须接受它并进行调整。
所以这就是现实：无法保证最低延迟的稳定性。
特别是在一个有这么多中间阶段的环境中。
对不起，Renat，但这不可能是网络延迟。
你就不能检查一下吗？ 在你的基础设施上。通过张贴公开市场第一分钟的日志？
如果我们几乎无法控制任何东西，那还有什么可检查的呢。
他们已经在市场开幕式上展示了具有规范证明的测试。但显然，这是一个一物降一物的案例。
我在上面已经说过几次，延迟的稳定性是无法保证的。
如果我们是一个经纪人，那将是另一回事--我们不会吝啬最有效的基础设施，并优化最大数量的路线。
对不起，Renat，但这不可能是网络延迟。
你只考虑到了你的网络延迟。你做得很好。而离你几步之遥，一切都很好。
问题出在其他地方。请阅读上述所有内容。也许还能读懂字里行间的意思。
对不起，Renat，但这不可能是网络延迟。