接受SL/TP订单 - 页 4 12345678 新评论 fxsaber 2020.11.30 21:26 #31 Enrique Dangeroux: https://www.mql5.com/ru/forum/341117 仍然是当前的一个问题 我最后一次检查时，这个问题在上述经纪人身上得到了解决。 fxsaber 2020.12.04 09:51 #32 亲爱的开发者，请回答以下关于架构的问题。这些信息是战斗申请所需要的。没有索赔。 有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？ 对于这个问题，我有几个答案。 在地段上。 关于票号。 从最后修改的开盘价 来看。 从订单的最后一次修改开始（例如，在限价订单中更新了拿货水平）。 如果我理解正确，那么在修改开盘价后，限制器会被适当地建立在服务器所有限制器的列表表中，并按开盘价排序。那么问题的答案就归结为，它是嵌入在价格相同的订单列表的开头还是在最后？ 同样的问题不是关于限制，而是关于代币。触发相同拍摄的顺序取决于什么？是身份证的位置还是别的什么？ 让我解释一下这在战斗中会有什么帮助。例如，我在同一水平上有两个限制器（或位置发球器），但手数不同。如果限价器（tee）的执行取决于最后的修改，那么我可以通过增加手数来修改限价器来提高FillRate。 也许，只有编写了相应MT5服务器部分实现的人知道这个问题的答案。 secret 2020.12.04 18:43 #33 Andrei Trukhanovich:与经纪人一起工作，找到瓶颈 这是什么？"蜜蜂与蜂蜜 "的关系？） Andrey Khatimlianskii 2020.12.04 21:25 #34 fxsaber:有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？对于这个问题，我有几个答案。 在地段上。 关于票号。 从最后修改的开盘价 来看。 从订单的最后一次修改开始（例如，在限价时更新了拿货水平）。 我认为变体4是在第四个中使用的。也就是说，任何修改都会把订单移到相应价格水平的队列末端。 Andrei Trukhanovich 2020.12.04 21:35 #35 secret: 这就像，蜜蜂与蜂蜜的关系？) 在这个特定的时刻，在这个特定的情况下，它是互利的，而且已经做了。 一个罕见的巧合。 fxsaber 2020.12.09 00:28 #36 MT5中的TP订单很了不起，你可以调查FillRate（订单的哪一部分被填补）。 对数以万计的此类订单的分析表明，FillRate在很大程度上取决于符号。如果一揽子TP订单同时被触发，那么FillRate将随着一揽子订单数量的增加而减少。 其他具体的细微差别也被揭示出来。但这是已经与经纪人讨论过的。 提高FillRate的秘诀：将所有相同的点位和限价器合并为一个共同的MT5限价器。 然而，这些数据只是这个话题的一个补充。独立于经纪商的问题是，MT5的ticks滞后，因此接受挂单（包括SL/TP水平）也滞后。 而在重定向后，MT5每次都会等待下一个tick来检查价格是否满足TP水平（或限制）。这可能需要几秒钟的时间。而且，检查应该总是在重排（或部分填充）后立即进行。 附加的文件： CheckOrders2.mq5 10 kb fxsaber 2020.12.11 08:17 #37 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 对于那些通过套利来剥离厨房经纪人的人来说，这种内置的滞后性就像来自天堂的法力。也就是说，经纪人会产生大量的额外风险。 Renat Fatkhullin 2021.01.20 08:56 #38 你是在哪个服务器上检查的？你用什么工具和什么网关/数据链来形成初始数据？如果时间是由报价提供商在其远程端（如交易所网关）生成的，而不是MT5服务器本身，那么可能会有一个缺口。你可以忘记哪些背景程序，例如有几万和几十万个平行交易 的压力测试？ fxsaber 2021.01.20 09:09 #39 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%的保证。然而，上述情况表明，即使在你的服务器上也存在这个问题。 Renat Fatkhullin 2021.01.20 11:45 #40 fxsaber:在调查TP订单执行时，我注意到一些TP订单的创建与接受它们的点位有很大的滞后。汇报显示，这种情况不仅在不同的经纪商上重复出现，而且在与交易服务器在同一台机器上的终端上进行交易时也是如此。也就是用一个非常低的ping和一个交易服务器的交易账户。 我鼓励你们分享你们账户的结果。帮助改进MT5! 你 "忘记 "了一个非常小的细节--你检查了58,000个订单，只发现了一个在300毫秒时出现过冲的案例。而在这些检查中，你应该清楚地关注这一点（58000中的1）。 就像之前的百万美元支票一样，你也是在寻找单一的异常点，并假装这是正常行为。 我们检查了服务器的日志，我们可以看到，我们的虚拟化与MetaQuotes-Demo服务器在那几秒钟内（在2020.09.30 19:07为4秒）身体不适，因为有大约15百万的账户和大约2百万的开仓，同时，在邻近的虚拟服务器和管理程序上也发生了一些事情。 在任何情况下，我们都会进一步研究，尽管任何系统中都有单个离群值。 12345678 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
https://www.mql5.com/ru/forum/341117 仍然是当前的一个问题
我最后一次检查时，这个问题在上述经纪人身上得到了解决。
亲爱的开发者，请回答以下关于架构的问题。这些信息是战斗申请所需要的。没有索赔。
有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？
对于这个问题，我有几个答案。
如果我理解正确，那么在修改开盘价后，限制器会被适当地建立在服务器所有限制器的列表表中，并按开盘价排序。那么问题的答案就归结为，它是嵌入在价格相同的订单列表的开头还是在最后？
同样的问题不是关于限制，而是关于代币。触发相同拍摄的顺序取决于什么？是身份证的位置还是别的什么？
让我解释一下这在战斗中会有什么帮助。例如，我在同一水平上有两个限制器（或位置发球器），但手数不同。如果限价器（tee）的执行取决于最后的修改，那么我可以通过增加手数来修改限价器来提高FillRate。
也许，只有编写了相应MT5服务器部分实现的人知道这个问题的答案。
与经纪人一起工作，找到瓶颈
有两个价格相同、手数不同的限价器。它们在激活触发序列中的顺序取决于什么？
对于这个问题，我有几个答案。
我认为变体4是在第四个中使用的。也就是说，任何修改都会把订单移到相应价格水平的队列末端。
这就像，蜜蜂与蜂蜜的关系？)
在这个特定的时刻，在这个特定的情况下，它是互利的，而且已经做了。 一个罕见的巧合。
MT5中的TP订单很了不起，你可以调查FillRate（订单的哪一部分被填补）。
对数以万计的此类订单的分析表明，FillRate在很大程度上取决于符号。如果一揽子TP订单同时被触发，那么FillRate将随着一揽子订单数量的增加而减少。
其他具体的细微差别也被揭示出来。但这是已经与经纪人讨论过的。
提高FillRate的秘诀：将所有相同的点位和限价器合并为一个共同的MT5限价器。
然而，这些数据只是这个话题的一个补充。独立于经纪商的问题是，MT5的ticks滞后，因此接受挂单（包括SL/TP水平）也滞后。
而在重定向后，MT5每次都会等待下一个tick来检查价格是否满足TP水平（或限制）。这可能需要几秒钟的时间。而且，检查应该总是在重排（或部分填充）后立即进行。
OnTick是在tick被写入交易服务器的几毫秒后触发的。
结果。
处理了100只蜱虫。服务器和蜱虫终端之间的到达滞后从1到8毫秒不等。平均为4毫秒多一点。这正好等于TP订单触发的滞后，这也是这个分支的起点。
滞后本身是在MT5服务器内部。服务器->终端通道与此无关。
恳请开发商消除这种滞后。现在，在零ping的情况下，我们有一个持续的延迟ticks，不仅传入终端，而且传入服务器。特别是，命令接受。
ZS 对于那些通过套利来剥离厨房经纪人的人来说，这种内置的滞后性就像来自天堂的法力。也就是说，经纪人会产生大量的额外风险。
Renat Fatkhullin:
На каком сервере проверяли?
在许多服务器上进行了检查。包括MQ-Demo。
关于交易、自动交易系统和交易策略测试的论坛
接受SL/TP订单
fxsaber, 2020.11.25 00:47
在MQ-Demo上运行的结果。
该脚本声称找到了一个TP订单和一个触发其产生的tick（文本中用颜色突出显示）。看起来，如果价格已经达到交易服务器上未平仓头寸的TP水平（特别是在模拟交易中），相应的TP订单应该立即创建（不一定执行）。然而，在这种情况下，它不是立即发生的，而是在357毫秒后发生的。
在哪个仪器和哪个网关/数据链上形成了初始数据？
我检查了外汇工具、RannForex-Server、AMTS-gateway。其他配置需要澄清。
我相信，MT5服务器是在一台零ping的机器上形成的。但需要澄清的是，100%的保证。然而，上述情况表明，即使在你的服务器上也存在这个问题。
在调查TP订单执行时，我注意到一些TP订单的创建与接受它们的点位有很大的滞后。
汇报显示，这种情况不仅在不同的经纪商上重复出现，而且在与交易服务器在同一台机器上的终端上进行交易时也是如此。也就是用一个非常低的ping和一个交易服务器的交易账户。
我鼓励你们分享你们账户的结果。帮助改进MT5!你 "忘记 "了一个非常小的细节--你检查了58,000个订单，只发现了一个在300毫秒时出现过冲的案例。而在这些检查中，你应该清楚地关注这一点（58000中的1）。
就像之前的百万美元支票一样，你也是在寻找单一的异常点，并假装这是正常行为。
我们检查了服务器的日志，我们可以看到，我们的虚拟化与MetaQuotes-Demo服务器在那几秒钟内（在2020.09.30 19:07为4秒）身体不适，因为有大约15百万的账户和大约2百万的开仓，同时，在邻近的虚拟服务器和管理程序上也发生了一些事情。
在任何情况下，我们都会进一步研究，尽管任何系统中都有单个离群值。