接受SL/TP订单 - 页 3 12345678 新评论 fxsaber 2020.11.26 10:36 #21 fxsaber:不幸的是,我们不可能监测待定订单的接受情况,因为终端上没有这个信息。但几乎无一例外的是,在执行订单时,TP/SL订单方面存在明显的滞后,不能不影响滞后。由于原因似乎是同一性质的。 从交易服务器上获取的限制器触发日志。 2020.11.26 09:32:23.053 '': order [#199 sell limit 0.01 EURSEK at 10.15957] triggered, activation price 10.16102 [10.16102 / 10.16354] 接受-挑剔。 限制器执行时有3ms的滞后。可能是非常昂贵的保证金正确性检查,等等。 也许服务器上有一个选项可以禁用检查。 到目前为止,中间的结论是,无论是TP/SL水平还是订单,其滞后的性质都是一样的。 HH这个tick是在09:32:23.050写入MT5数据库的,但在这之前交易服务器机器上是09:32:23.039。也就是提前11毫秒。总共14(11+3)ms的滞后。 Dmitry Fedoseev 2020.11.26 11:49 #22 人的生活)。3毫秒是个问题。 fxsaber 2020.11.26 13:02 #23 Dmitry Fedoseev: 人民生活))。三毫秒是个问题。 这是在一个完全空的贸易服务器上,CPU负载为零。 上面的例子是在MQ-Demo上的数百毫秒。 因为它是,即使是三毫秒也经常是重定向的原因。这就像因为交通灯而赶不上飞机。 fxsaber 2020.11.26 13:16 #24 fxsaber:HH MT5数据库在09:32:23.050记录了嘀嗒声,但在这之前有交易服务器的机器在09:32:23.039打出。也就是提前11毫秒。总共14(11+3)ms的滞后。 也请检查向MT5基数写入点子的速度。 Aleksandr Slavskii 2020.11.26 14:29 #25 我的真实账户上 只有一个订单是在外卖上成交的,这并不奇怪,股票)))。 QD 0 21:14:14.049 CheckOrders (GAZP,D1) ServerName: Open-Broker MN 0 21:14:14.049 CheckOrders (GAZP,D1) LF 0 21:14:14.078 CheckOrders (GAZP,D1) Last Tick 2020.11.13 21:45:51.656 180.84 180.89 CK 0 21:14:14.078 CheckOrders (GAZP,D1) Accepted Tick 2020.11.13 21:45:51.656 180.84 180.89 PS 0 21:14:14.078 CheckOrders (GAZP,D1) Accepted Length = 14 ms. EK 0 21:14:14.078 CheckOrders (GAZP,D1) Order 139999826 ORDER_TYPE_SELL GAZP 2020.11.13 21:45:51.670 180.84 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11.13 21:45:51.670, Position 139820013 created 2020.11.12 20:41:42.184, StopLevel = 0 fxsaber 2020.11.27 09:03 #26 Aleksandr Slavskii:我的真实账户上 只有一个订单在拿货时关闭,这并不奇怪,股票)))。 你有一个非常酷的情况。 的真实账户上 只有一个订单是以取值关闭的,这不是一个惊喜,是一只股票))) Order 139999826 ORDER_TYPE_SELL GAZP 2020.11.13 21:45:51.670 180.84 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11.13 21:45:51.670, Position 139820013 created 2020.11.12 20:41:42.184, StopLevel = 0 TP命令的诞生时间和执行时间以一毫秒的精度重合。也许,这就是交流的特殊性。 但接单出生时间为14毫秒。这对股票市场的交易来说是一个很大的数字。 fxsaber 2020.11.27 20:20 #27 似乎已经找到了原因。在服务器运行的机器上运行该脚本。 // Преобразование времени в миллисекундах в строку. string TimeToString( const long time, const int FlagTime = TIME_DATE | TIME_SECONDS) { return(TimeToString((datetime)time / 1000, FlagTime) + "." + IntegerToString(time % 1000, 3, '0')); } // Преобразование тика в строку. string TickToString( const MqlTick &Tick, const int digits ) { return(TimeToString(Tick.time_msc) + " " + DoubleToString(Tick.bid, digits) + " " + DoubleToString(Tick.ask, digits)); } void OnTick() { MqlTick Tick; if (SymbolInfoTick(_Symbol, Tick)) Print(TickToString(Tick, _Digits)); } 结果。 2020.11.27 22:13:44.156 2020.11.27 22:13:44.149 1.59953 1.59993 2020.11.27 22:13:44.862 2020.11.27 22:13:44.855 0.98789 0.98837 2020.11.27 22:13:45.263 2020.11.27 22:13:45.258 0.98789 0.98839 2020.11.27 22:13:46.878 2020.11.27 22:13:46.873 10.15554 10.16084 2020.11.27 22:13:48.993 2020.11.27 22:13:48.991 10.15554 10.16106 2020.11.27 22:13:51.722 2020.11.27 22:13:51.716 0.98789 0.98840 2020.11.27 22:13:53.035 2020.11.27 22:13:53.027 1.59950 1.59995 2020.11.27 22:13:53.134 2020.11.27 22:13:53.128 1.59954 1.59995 2020.11.27 22:13:53.737 2020.11.27 22:13:53.734 0.98789 0.98839 2020.11.27 22:13:54.745 2020.11.27 22:13:54.743 0.98789 0.98840 2020.11.27 22:13:56.768 2020.11.27 22:13:56.761 0.98789 0.98839 2020.11.27 22:13:57.977 2020.11.27 22:13:57.973 1.59954 1.59994 2020.11.27 22:14:00.293 2020.11.27 22:14:00.292 10.15554 10.16093 2020.11.27 22:14:04.131 2020.11.27 22:14:04.125 1.59954 1.59995 2020.11.27 22:14:08.868 2020.11.27 22:14:08.866 0.98789 0.98841 2020.11.27 22:14:09.780 2020.11.27 22:14:09.773 0.98789 0.98840 2020.11.27 22:14:09.981 2020.11.27 22:14:09.975 1.59955 1.59994 2020.11.27 22:14:10.085 2020.11.27 22:14:10.076 1.59957 1.59994 2020.11.27 22:14:10.180 2020.11.27 22:14:10.177 1.59957 1.59995 左边是打印时间。右边是传入的勾股的时间。可以清楚地看到滞后的情况。看起来,OnTick的触发时间比tick被写入交易服务器的时间晚了几毫秒。 似乎服务器负责订单激活的部分被延迟了,就像他们到达终端时发生的那样。 Enrique Dangeroux 2020.11.30 18:04 #28 fxsaber : 我也有一整本日记,里面都是这样的信息。也许周末之后情况会有所改变。 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] 走了。 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Total Orders (from 2020.11.30 00:00:00) = 899, calculated = 58 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Calculation time = 00:00:00.000 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) ServerName: RannForex-Server 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:45.786 104.369 104.369 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 1077 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774962 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:45.789 104.365 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11.30 19:07:45.802, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Orders (6) before 1774962 with PositionID = 1774955: 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) ------------------------ 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.766 104.366 104.366 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.766 104.366 104.366 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 2 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774959 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.768 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.780, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.874 104.367 104.367 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 164 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774960 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.876 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.900, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.940 104.368 104.368 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 230 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774961 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.942 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.954, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Checked Orders = 3 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) ------------------------ fxsaber 2020.11.30 20:37 #29 Enrique Dangeroux:走了。 你的日志完全证实了重复的TP订单只有在新的tick到达后才会形成。 关于交易、自动交易系统和交易策略测试的论坛 接受SL/TP订单 Enrique Dangeroux, 2020.11.30 19:04 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:45.786 104.369 104.369 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 1077 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774962 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:45.789 104.365 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11.30 19:07:45.802, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Orders (6) before 1774962 with PositionID = 1774955: 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) ------------------------ 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.766 104.366 104.366 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.766 104.366 104.366 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 2 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774959 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.768 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.780, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.874 104.367 104.367 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 164 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774960 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.876 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.900, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Last Tick 2020.11.30 19:07:44.940 104.368 104.368 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Tick 2020.11.30 19:07:44.712 104.365 104.365 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Accepted Length = 230 ms. 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Order 1774961 ORDER_TYPE_SELL USDJPY 2020.11.30 19:07:44.942 104.365 ORDER_REASON_TP ORDER_STATE_REJECTED 2020.11.30 19:07:44.954, Position 1774955 created 2020.11.30 19:07:22.655, StopLevel = 0 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) Checked Orders = 3 2020.11.30 18:52:09.327 OrderCheck (GBPAUD,H1) ------------------------ 在很多其他类似的日志上(今天)一直与经纪人处理这些情况。 Enrique Dangeroux 2020.11.30 21:10 #30 https://www.mql5.com/ru/forum/341117 仍然是当前的一个问题 至于该杂志,没有 "贸易设置"。 12345678 新评论 原因: 取消 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
不幸的是,我们不可能监测待定订单的接受情况,因为终端上没有这个信息。但几乎无一例外的是,在执行订单时,TP/SL订单方面存在明显的滞后,不能不影响滞后。由于原因似乎是同一性质的。
从交易服务器上获取的限制器触发日志。
2020.11.26 09:32:23.053 '': order [#199 sell limit 0.01 EURSEK at 10.15957] triggered, activation price 10.16102 [10.16102 / 10.16354]
接受-挑剔。
限制器执行时有3ms的滞后。可能是非常昂贵的保证金正确性检查,等等。
也许服务器上有一个选项可以禁用检查。
到目前为止,中间的结论是,无论是TP/SL水平还是订单,其滞后的性质都是一样的。
HH这个tick是在09:32:23.050写入MT5数据库的,但在这之前交易服务器机器上是09:32:23.039。也就是提前11毫秒。总共14(11+3)ms的滞后。
人民生活))。三毫秒是个问题。
这是在一个完全空的贸易服务器上,CPU负载为零。
上面的例子是在MQ-Demo上的数百毫秒。
因为它是,即使是三毫秒也经常是重定向的原因。这就像因为交通灯而赶不上飞机。
HH MT5数据库在09:32:23.050记录了嘀嗒声,但在这之前有交易服务器的机器在09:32:23.039打出。也就是提前11毫秒。总共14(11+3)ms的滞后。
也请检查向MT5基数写入点子的速度。
我的真实账户上 只有一个订单是在外卖上成交的,这并不奇怪,股票)))。
我的真实账户上 只有一个订单在拿货时关闭,这并不奇怪,股票)))。
你有一个非常酷的情况。
的真实账户上 只有一个订单是以取值关闭的,这不是一个惊喜,是一只股票)))
TP命令的诞生时间和执行时间以一毫秒的精度重合。也许,这就是交流的特殊性。
但接单出生时间为14毫秒。这对股票市场的交易来说是一个很大的数字。
似乎已经找到了原因。在服务器运行的机器上运行该脚本。
结果。
左边是打印时间。右边是传入的勾股的时间。可以清楚地看到滞后的情况。看起来,OnTick的触发时间比tick被写入交易服务器的时间晚了几毫秒。
似乎服务器负责订单激活的部分被延迟了,就像他们到达终端时发生的那样。
我也有一整本日记,里面都是这样的信息。也许周末之后情况会有所改变。
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]
走了。
走了。
你的日志完全证实了重复的TP订单只有在新的tick到达后才会形成。
关于交易、自动交易系统和交易策略测试的论坛
接受SL/TP订单
Enrique Dangeroux, 2020.11.30 19:04
在很多其他类似的日志上(今天)一直与经纪人处理这些情况。
https://www.mql5.com/ru/forum/341117 仍然是当前的一个问题
至于该杂志,没有 "贸易设置"。