MT5和速度在行动 - 页 69 1...626364656667686970717273747576...94 新评论 Roman 2020.11.04 20:48 #681 Andrei Trukhanovich:你是如何设想的--在一个线程中进行并行处理？ 一个事件循环。 而一般来说，这是开发人员的问题，为什么所有的东西都在一个线程中执行。 事实证明，市场概览是异步处理的，而用户程序中的处理程序是同步处理的。 这是很难得的，没有什么可说的。 fxsaber 2020.11.04 22:14 #682 谢谢你对统计数字的反馈!OnTick/OnBook的滞后性似乎对每个人来说都是存在的。Sleep(1)是1ms或15ms。目前还不清楚为什么会有这种情况。 pivomoe 2020.11.05 01:34 #683 fxsaber:每个人似乎都有OnTick/OnBook的滞后。 我想你知道，OnTimer()的调用频率不能超过10-16毫秒。 符合逻辑的是，其他的OnXXX函数也不会被频繁调用。也许这就是你的滞后发生的原因？ Renat Fatkhullin 2020.11.05 02:35 #684 pivomoe:我想你知道，OnTimer()的调用频率不能超过10-16毫秒。 符合逻辑的是，其他的OnXXX函数也不会被频繁调用。也许这就是你滞后的原因？ 在逻辑上不是，处理程序并不与GetTickCount计时器的频率/分辨率相联系。事件在发生的那一刻就会被即时触发。 OnTimer也没有绑定到16ms的错误。在绝大多数情况下，很容易得到一个1毫秒的计时器，除非电脑已经死了，而且是100%负载。 fxsaber的几乎所有测试的问题是，他试图测量单个调用的离群值，而不是对集合进行平均，并且不想了解线程调度器的现实。 他有。 在4/8核心上至少有1500-2000个线程 可怜的同伴线程管理器将线程分配给数量少得惊人的演员--人们没有意识到他们的任务有数百个竞争对手 偶尔会有优先级的线程被唤醒，这些线程在短时间内比其他线程占用更多的时间量。 任何线程都可以在任何时候离开低谷相当长的时间--在一个微不足道的i++上就是几毫秒（我必须说多少次？） 争取接近复职时间的方法。 更多的核心来破坏线程管理器 绝对是新的CPU，具有现代的缓存，良好的时钟速度和增加的IPC 更快的内存和nvme磁盘，这极大地消除了任何第三方食欲的影响 正确的驱动程序和bios，使普通的网络接口不会默默地破坏中断（在虚拟机中尤其可怕，ISP管理员不仅没有意识到这个问题，而且他们一般不熟悉延迟、SR-IOV和解锁/解锁瓶颈。） 一个中型的独立显卡，能够减轻操作系统和程序界面渲染的任何2D负载（在服务器和虚拟桌面上总是很痛苦）。 减少未使用的进程/程序的数量 减少不必要的外围硬件和驱动程序的数量 因此，在一个普通的VPS上，终端（以及任何其他程序）将总是遭受意外的延迟。越是廉价/过度销售的VPS，问题就越多。 问问你自己，在你的VPS上，是否启用了SR-IOV，是否有任何最新的（仅手动安装的）特殊网络驱动用于它？在99%的情况下，不会，因为它破坏了跨硬件动物园的虚拟化迁移。如果没有它，仅仅因为双重（在主机和虚拟）网络数据包传输/处理和增加的中断数量，就可以保证额外的延迟。 我们的VPS服务在架构 和没有GUI的轻量级终端方面都更不容易出现这种情况。 Roman 2020.11.05 04:34 #685 Renat Fatkhullin:不符合逻辑，处理程序不与GetTickCount计时器频率/分辨率挂钩。事件在发生的时候就会被即时触发。OnTimer也没有绑定到16ms的错误。在绝大多数情况下，很容易得到一个1毫秒的计时器，除非电脑已经死了，而且是100%负载。 fxsaber的几乎所有测试的问题是，他试图测量单个调用的离群值，而不是对集合进行平均，并且不想了解线程调度器的现实。 他有。 在4/8核心上至少有1500-2000个线程 可怜的同伴线程管理器将线程分配给数量少得惊人的角色--人们没有意识到他们的任务有数百个竞争者 偶尔会有优先级的线程被唤醒，这些线程在短时间内比其他线程占用更多的时间量。 任何线程都可以在任何时候离开低谷相当长的时间--在一个微不足道的i++上就是几毫秒（我必须说多少次？） 争取接近复职时间的方法。 更多的核心来破坏线程管理器 绝对是新的CPU，具有现代的缓存，良好的时钟速度和增加的IPC 更快的内存和nvme磁盘，这极大地消除了任何第三方胃口的影响 正确的驱动程序和BIOS，这样一个微不足道的网络接口就不会悄悄地破坏中断（在虚拟机中尤其可怕，ISP管理员不仅没有意识到这个问题，而且他们通常不熟悉延迟、SR-IOV和去瓶颈。） 一个平庸的独立显卡，能够减轻操作系统和程序界面渲染的任何2D负载（在服务器和虚拟桌面上总是很痛苦）。 减少未使用的进程/程序的数量 减少不必要的外围硬件和驱动程序的数量 因此，在一个普通的VPS上，终端（以及任何其他程序）将总是遭受意外的延迟。越是廉价/过度销售的VPS，问题就越多。 问问你自己，在你的VPS上，是否启用了SR-IOV，是否有任何最新的（仅手动安装的）特殊网络驱动用于它？在99%的情况下，不会，因为它破坏了跨硬件动物园的虚拟化迁移。如果没有它，仅仅因为双重（在主机和虚拟）网络数据包传输/处理和增加的中断数量，就可以保证额外的延迟。 我们的VPS服务受到它的影响要小得多，无论是在结构上 还是在没有GUI的轻量级终端上。 现在想象一下，如果程序中的处理程序以异步方式执行，那么在这样一台优化的机器上，用户程序的性能会慢多少倍。 如果用户程序中的处理程序先验地同步执行，我不明白机器硬件的超级升级和超级优化的意义。 对于终端本身及其内部运作，也许，上述的优化是有用的。对于用户战斗程序，我表示怀疑。 因为在用户程序中连续执行处理程序会降低任何超级优化的机器的所有潜力。 问题不在硬件上，而是在终端内部工作的架构上。 Slava 2020.11.05 06:30 #686 Roman:现在想象一下，如果程序中的处理程序将被异步执行，那么在这样一个优化的机器上，用户程序的运行将快多少倍。 如果用户程序中的处理程序先验地同步执行，我不明白机器硬件的超级升级和超级优化的意义。 对于终端本身及其内部运作，也许，上述的优化是有用的。对于用户战斗程序，我表示怀疑。 因为在用户程序中连续执行处理程序会降低任何超级优化的机器的所有潜力。 问题不在硬件上，而是在终端内部操作的架构上。 将不会有加速。请提交你的计算结果，至少要有近似的数字，证明一个多重加速度。 争夺资源？不受控制地创建新线程？无所事事的冲突？ 你想要不明原因的减速吗？ 在基于事件的模型 中，所有的事件总是以编队的方式进行，一次一个。嚼碎了 - 嚼碎了。 fxsaber 2020.11.05 06:42 #687 Renat Fatkhullin:我们的VPS服务在架构 和没有GUI的轻量级终端方面都更不容易发生这种情况。 如果你的VPS服务有滞后现象，你会认真对待吗？ 谁使用MQ的VPS，请在那里分享以下程序的结果。 专家顾问，它抓住了滞后的OnTick/OnBook。 专家顾问，用旧的时间抓取蜱虫。 一个 测量Sleep(1)平均执行时间的脚本。 fxsaber 2020.11.05 06:42 #688 我怎样才能让Sleep(1)运行得更快？ Renat Fatkhullin 2020.11.05 06:53 #689 fxsaber:如果你的VPS服务有滞后现象 - 你会认真对待吗？ 我不知道要告诉你多少次，在每个有限的核心数量上有这么多（成千上万）线程的情况下，谈论每个线程的时间量子分配的稳定性是疯狂的？ 你总是能保证在任何 指令的随机单个样本上出现失败 ，包括最简单的汇编程序，如inc eax。这是架构上的原因，也是由于 "诚实地将成千上万个线程的时间量子分配给少数核心 "的物理限制。 不要再犯傻了，继续捕捉每百万次请求中的单次突发。 fxsaber 2020.11.05 07:00 #690 Renat Fatkhullin:不要再犯傻了，继续抓取每百万次查询中的单个异常值。 我明白了单峰是怎么回事，谢谢你的详细解释。目前我们讨论的不是SymbolInfoTick，而是另一种滞后，它几乎发生在每个tick 上。 1...626364656667686970717273747576...94 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
你是如何设想的--在一个线程中进行并行处理？
一个事件循环。
而一般来说，这是开发人员的问题，为什么所有的东西都在一个线程中执行。
事实证明，市场概览是异步处理的，而用户程序中的处理程序是同步处理的。
这是很难得的，没有什么可说的。
谢谢你对统计数字的反馈!OnTick/OnBook的滞后性似乎对每个人来说都是存在的。Sleep(1)是1ms或15ms。目前还不清楚为什么会有这种情况。
每个人似乎都有OnTick/OnBook的滞后。
我想你知道，OnTimer()的调用频率不能超过10-16毫秒。 符合逻辑的是，其他的OnXXX函数也不会被频繁调用。也许这就是你的滞后发生的原因？
我想你知道，OnTimer()的调用频率不能超过10-16毫秒。 符合逻辑的是，其他的OnXXX函数也不会被频繁调用。也许这就是你滞后的原因？
在逻辑上不是，处理程序并不与GetTickCount计时器的频率/分辨率相联系。事件在发生的那一刻就会被即时触发。
OnTimer也没有绑定到16ms的错误。在绝大多数情况下，很容易得到一个1毫秒的计时器，除非电脑已经死了，而且是100%负载。
fxsaber的几乎所有测试的问题是，他试图测量单个调用的离群值，而不是对集合进行平均，并且不想了解线程调度器的现实。
他有。
争取接近复职时间的方法。
因此，在一个普通的VPS上，终端（以及任何其他程序）将总是遭受意外的延迟。越是廉价/过度销售的VPS，问题就越多。
问问你自己，在你的VPS上，是否启用了SR-IOV，是否有任何最新的（仅手动安装的）特殊网络驱动用于它？在99%的情况下，不会，因为它破坏了跨硬件动物园的虚拟化迁移。如果没有它，仅仅因为双重（在主机和虚拟）网络数据包传输/处理和增加的中断数量，就可以保证额外的延迟。
我们的VPS服务在架构 和没有GUI的轻量级终端方面都更不容易出现这种情况。
不符合逻辑，处理程序不与GetTickCount计时器频率/分辨率挂钩。事件在发生的时候就会被即时触发。
OnTimer也没有绑定到16ms的错误。在绝大多数情况下，很容易得到一个1毫秒的计时器，除非电脑已经死了，而且是100%负载。
fxsaber的几乎所有测试的问题是，他试图测量单个调用的离群值，而不是对集合进行平均，并且不想了解线程调度器的现实。
他有。
争取接近复职时间的方法。
因此，在一个普通的VPS上，终端（以及任何其他程序）将总是遭受意外的延迟。越是廉价/过度销售的VPS，问题就越多。
问问你自己，在你的VPS上，是否启用了SR-IOV，是否有任何最新的（仅手动安装的）特殊网络驱动用于它？在99%的情况下，不会，因为它破坏了跨硬件动物园的虚拟化迁移。如果没有它，仅仅因为双重（在主机和虚拟）网络数据包传输/处理和增加的中断数量，就可以保证额外的延迟。
我们的VPS服务受到它的影响要小得多，无论是在结构上 还是在没有GUI的轻量级终端上。
现在想象一下，如果程序中的处理程序以异步方式执行，那么在这样一台优化的机器上，用户程序的性能会慢多少倍。
如果用户程序中的处理程序先验地同步执行，我不明白机器硬件的超级升级和超级优化的意义。
对于终端本身及其内部运作，也许，上述的优化是有用的。对于用户战斗程序，我表示怀疑。
因为在用户程序中连续执行处理程序会降低任何超级优化的机器的所有潜力。
问题不在硬件上，而是在终端内部工作的架构上。
现在想象一下，如果程序中的处理程序将被异步执行，那么在这样一个优化的机器上，用户程序的运行将快多少倍。
如果用户程序中的处理程序先验地同步执行，我不明白机器硬件的超级升级和超级优化的意义。
对于终端本身及其内部运作，也许，上述的优化是有用的。对于用户战斗程序，我表示怀疑。
因为在用户程序中连续执行处理程序会降低任何超级优化的机器的所有潜力。
问题不在硬件上，而是在终端内部操作的架构上。
将不会有加速。请提交你的计算结果，至少要有近似的数字，证明一个多重加速度。
争夺资源？不受控制地创建新线程？无所事事的冲突？
你想要不明原因的减速吗？
在基于事件的模型 中，所有的事件总是以编队的方式进行，一次一个。嚼碎了 - 嚼碎了。
我们的VPS服务在架构 和没有GUI的轻量级终端方面都更不容易发生这种情况。
如果你的VPS服务有滞后现象，你会认真对待吗？
谁使用MQ的VPS，请在那里分享以下程序的结果。
如果你的VPS服务有滞后现象 - 你会认真对待吗？
我不知道要告诉你多少次，在每个有限的核心数量上有这么多（成千上万）线程的情况下，谈论每个线程的时间量子分配的稳定性是疯狂的？
你总是能保证在任何 指令的随机单个样本上出现失败 ，包括最简单的汇编程序，如inc eax。这是架构上的原因，也是由于 "诚实地将成千上万个线程的时间量子分配给少数核心 "的物理限制。
不要再犯傻了，继续捕捉每百万次请求中的单次突发。
不要再犯傻了，继续抓取每百万次查询中的单个异常值。
我明白了单峰是怎么回事，谢谢你的详细解释。目前我们讨论的不是SymbolInfoTick，而是另一种滞后，它几乎发生在每个tick 上。