MT5和速度在行动 - 页 92 1...85868788899091929394 新评论 Vasiliy Pushkaryov 2021.07.29 14:21 #911 fxsaber:监测TimeLocal和TimeCurrent 之间的差异。 而如果TimeLocal()在这些情况下会滞后，原因是否在操作系统？ fxsaber 2021.07.29 14:22 #912 Vasiliy Pushkaryov: 而如果TimeLocal()在这种情况下会滞后，原因是否在操作系统？ TimeLocal 也不甘落后。这个差异是一个经纪人。 Andrei Trukhanovich 2021.07.29 14:32 #913 Vasiliy Pushkaryov:也许有人有经验，什么原因会导致这种挂起或减速？ 首先想到的是代码中的一个bug，它导致计算运行很长的时间（例如，在从1到10的循环中，由于这个bug，整个int都在运行）。 Vasiliy Pushkaryov 2021.07.29 14:41 #914 fxsaber:TimeLocal 也不甘落后。这个差异是一个经纪人。 谢谢你。我会试一试的。 Vasiliy Pushkaryov 2021.07.29 14:49 #915 Andrei Trukhanovich:首先想到的是代码中的一个bug，它触发了一个需要很长时间的计算（例如，在从1到10的循环中，由于这个bug，整个int都在运行）。 帮助中写到，循环的EA不能干扰其他程序的工作。一切都冻结了，然后又开始工作。 我有7个MT4终端和3个MT5终端并联运行。也许能力不足？ Andrei Trukhanovich 2021.07.29 15:09 #916 Vasiliy Pushkaryov:帮助中似乎写到，循环的EA不能干扰其他程序。而在这里，一切都冻结了，然后一切又开始工作。 是的，很奇怪，我只看到了专家标签，我第一次没有看到日志。 有7个MT4终端和3个MT5终端并联运行。可能是能力不足？ 如果是这样，那么很可能所有的终端都会被减慢。另外，在这种情况下，CPU负载应该只是扩展到100%。 fxsaber 2021.08.02 20:47 #917 设置TerminalA - 有ping数据的终端（xxx ms）到接入点。 设置TerminalB - 没有ping数据的终端（不适用）到接入点。 两套系统的终端都可以连接到同一个接入点，并以同样的方式进行交易--发送订单 并收到回复。 终端A尽可能少地加载处理器。 终端B： 尽可能多地加载CPU。 重启后仍为终端B。 在 "重新扫描网络 "之后（通过GUI手动），将类型改为TerminalA。相应地，它停止加载CPU。 如果你遇到莫名其妙的高CPU负载，尝试重新扫描。这帮助我将所有TerminalB改为TerminalA。 fxsaber 2021.08.30 06:50 #918 我不知道为什么，但我的经纪人在MT5上的交易额、交易数量 和活跃交易账户数量似乎都比MT4上的多。 不幸的是，只有按平台划分的综合信息。 Количество закрытых позиций :129 714 Торговый оборот ($) :$ 5 747 296 372 Активных счетов :498 但间接证据表明，MT5领先于MT4。造成这种状况的原因只能是猜测。 我对客户的了解。 >95%的交易（~99%的营业额）是自动交易。 一些客户的MT5终端占用了>10G的内存（历史缓存），而相同容量的MT4则<1G。尽管如此，还是准备为更强大的VPS支付过高的费用，但正好在MT5上交易，而不是在4上交易。 几乎所有的人都是黄牛党。主要利润来自于夜间和晚间的平盘交易。 滚动期间的高活动（与其他经纪商相比是有利的一面）--巨大的点差。 Vasiliy Pushkaryov 2021.09.28 10:06 #919 fxsaber TimeCurrent 之间的差异。 谢谢你的提示。捕捉到这种情况。在OnTimer() 中监测到TimeLocal() 和TimeCurrent()之间的差异 从昨天晚上21:58开始，TimeCurrent() 开始返回相同的时间。今天00:08发布。也就是说，仅仅两个多小时，所有角色都出现了这种情况。 fxsaber 2022.01.19 10:28 #920 不是远程机器（不是VPS），有良好的规格，到交易服务器的ping<4ms，在查看 终端日志（b2958）时，看到了许多经常性滞后的情况。 我把我看到的第一件东西拿到这里做示范。 2022.01.18 23:00:09.375 Trades '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.752 Trades '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.769 Trades '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms 限制器的修改持续了8秒。大多数修改需要大约这个时间。 2022.01.18 23:11:00.751 Trades '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.761 Trades '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.763 Trades '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms 即使对于4毫秒的ping来说，这也是一个很大的问题，但与8秒相比仍然不算什么。 这台机器上只有MT5终端在运行，平均CPU负载为~1%。分析表明，在制动过程中，当市场和交易订单非常活跃时，负荷会激增到100%。因此，从交易服务器到终端接收响应需要很长的时间。在速度慢的情况下，我已经向经纪人询问了情况。在交易服务器方面，所有的事情都是即时的，订单在第一线从终端到达服务器。也就是说，订单的发送速度并不慢，滞后发生在接收终端的回复上。 我怀疑开发商能否在这里改进什么。谁在交易中非常活跃，请与你的日志分享你对这个话题的看法。 1...85868788899091929394 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
监测TimeLocal和TimeCurrent 之间的差异。
而如果TimeLocal()在这种情况下会滞后，原因是否在操作系统？
TimeLocal 也不甘落后。这个差异是一个经纪人。
也许有人有经验，什么原因会导致这种挂起或减速？
首先想到的是代码中的一个bug，它导致计算运行很长的时间（例如，在从1到10的循环中，由于这个bug，整个int都在运行）。
TimeLocal 也不甘落后。这个差异是一个经纪人。
首先想到的是代码中的一个bug，它触发了一个需要很长时间的计算（例如，在从1到10的循环中，由于这个bug，整个int都在运行）。
帮助中写到，循环的EA不能干扰其他程序的工作。一切都冻结了，然后又开始工作。
我有7个MT4终端和3个MT5终端并联运行。也许能力不足？
帮助中似乎写到，循环的EA不能干扰其他程序。而在这里，一切都冻结了，然后一切又开始工作。
是的，很奇怪，我只看到了专家标签，我第一次没有看到日志。
有7个MT4终端和3个MT5终端并联运行。可能是能力不足？
如果是这样，那么很可能所有的终端都会被减慢。另外，在这种情况下，CPU负载应该只是扩展到100%。
设置TerminalA - 有ping数据的终端（xxx ms）到接入点。
设置TerminalB - 没有ping数据的终端（不适用）到接入点。
两套系统的终端都可以连接到同一个接入点，并以同样的方式进行交易--发送订单 并收到回复。
终端A尽可能少地加载处理器。
终端B：
如果你遇到莫名其妙的高CPU负载，尝试重新扫描。这帮助我将所有TerminalB改为TerminalA。
我不知道为什么，但我的经纪人在MT5上的交易额、交易数量 和活跃交易账户数量似乎都比MT4上的多。
不幸的是，只有按平台划分的综合信息。
但间接证据表明，MT5领先于MT4。造成这种状况的原因只能是猜测。
我对客户的了解。
谢谢你的提示。捕捉到这种情况。在OnTimer() 中监测到TimeLocal() 和TimeCurrent()之间的差异
从昨天晚上21:58开始，TimeCurrent() 开始返回相同的时间。今天00:08发布。也就是说，仅仅两个多小时，所有角色都出现了这种情况。
不是远程机器（不是VPS），有良好的规格，到交易服务器的ping<4ms，在查看 终端日志（b2958）时，看到了许多经常性滞后的情况。
我把我看到的第一件东西拿到这里做示范。
2022.01.18 23:00:09.375 Trades '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.752 Trades '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709 2022.01.18 23:00:17.769 Trades '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms限制器的修改持续了8秒。大多数修改需要大约这个时间。
2022.01.18 23:11:00.751 Trades '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.761 Trades '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712 2022.01.18 23:11:00.763 Trades '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms即使对于4毫秒的ping来说，这也是一个很大的问题，但与8秒相比仍然不算什么。
这台机器上只有MT5终端在运行，平均CPU负载为~1%。分析表明，在制动过程中，当市场和交易订单非常活跃时，负荷会激增到100%。因此，从交易服务器到终端接收响应需要很长的时间。在速度慢的情况下，我已经向经纪人询问了情况。在交易服务器方面，所有的事情都是即时的，订单在第一线从终端到达服务器。也就是说，订单的发送速度并不慢，滞后发生在接收终端的回复上。
我怀疑开发商能否在这里改进什么。谁在交易中非常活跃，请与你的日志分享你对这个话题的看法。