MT5和速度在行动 - 页 89 1...82838485868788899091929394 新评论 traveller00 2021.03.01 13:16 #881 也许只要进行几次测试，问题就会消失？ Artyom Trishkin 2021.03.01 13:19 #882 traveller00: 也许只要进行几次测试，问题就会消失？ 也许。我希望我有更多的时间来自己做测试 :( fxsaber 2021.03.01 14:01 #883 traveller00: 也许只要进行几次测试，问题就会消失？ 测试只有在你第一次开始的时候才会显示出差异。 Vladimir Simakov 2021.03.01 14:11 #884 Slava:Symbol()，_Symbol条目等同于NULL（其中允许用NULL代替符号名）。在这种情况下，不需要额外检查当前符号的存在、当前符号在市场观察中的存在以及不必要地调用当前符号的属性，因为当前字符的属性已被缓存。也就是说，如果指定了一个普通的字符串参数，而不是Symbol()、_Symbol或NULL，那么就检查完整的程序和更多的属性调用 问题。 string symbol=_Symbol; SymbolInfoInteger(symbol,...) SymbolInfoInteger(NULL,...) - 在这两种情况下，SymbolInfoXXX 调用的行为，它们的差异会不会超过一个检查？ symbol==_Symbol ? traveller00 2021.03.01 20:41 #885 traveller00:顺便说一下，从今天最新发布的MT5版本的新鲜日志来看。这是在一个符号上盘旋的3个EA，每个都在自己的图表上。而这个要求每隔一段时间 就会继续下去。这样的峰值当然不常有，但事实上，1个来自最后一个tick的新ticks请求被执行了700毫秒。 我已经监测了大约12个小时，但我已经可以看到滞后性跨越了所有极限。 Time[Main.mqh 162 in ProcessTicks: CopyTicksRange(_Symbol,OldTicks,COPY_TICKS_INFO,LastTickParsed.time_msc)] = 8589203 mcs. 3个EA，每个都在自己的图表上，都在1个符号上，都在通过CopyTicksRange请求从前一个tick开始的旧ticks。而滞后的时间几乎为9秒。而且似乎这还不是极限。最有可能的是，Tick存储是一个共享资源，对它的访问是同步的，但即使是非常糟糕的同步，也不应该有这种时间。 有人会说这是一个一次性的小故障。在这12个小时的监测中，不幸的是，已经有超过100个1秒的退出。而这些看起来不再是一次性的突发事件。看起来经常有多个蜱虫同时进入，这就是造成这些尖峰的原因。 即使我们闭上眼睛，不看3个EA为一个共同的资源而争斗的事实，让我们看一下其他的监测。 ProcessTicks: CopyTicksRange(_Symbol,OldTicks,COPY_TICKS_INFO,LastTickParsed.time_msc)] = 1401285 mcs. 该符号上只有1个专家顾问。而且还是一秒半。它不是唯一的一个，还有其他符号的EA，但它不是多线程的吗？或者说不同符号的蜱虫仍然可以互相拖累？ 这是对基本EA的基本功能。该平台被定位为一个算法交易平台。这就是说，基本功能引起了强烈的质疑。一个很大的要求是再看一下。我几乎可以肯定在某处有改进的余地。或者，如果能像这里建议的那样，获得函数被调用后的最后几秒钟，我将非常感激 关于交易、自动交易系统和测试交易策略的论坛 MT5和速度在行动 fxsaber, 2021.03.01 07:28 请考虑这样的功能。 int SymbolInfoTicks( const string Symb, MqlTick &Ticks[] ); // Возвращает свежие тики (не более сотни), пришедшие с предыдущего вызова этой функции. 现在，只有通过CopyTicks*才能解决获得新刻度线而不跳过的问题。对于这项广泛的任务，这是一个非常繁琐的机制。这就像用大炮打鸟。 因此，刹车，保留巨大的缓存，等等。 fxsaber 2021.03.05 18:44 #886 尽量减少了对SymbolInfoTick和CopyTicksRange的调用。 SymbolInfoTick快照--每100µs不超过一次调用。 只有在市场观察中确实有新的刻度线到达时，才会调用新刻度线的CopyTicksRange。 终端和机器（交换文件被禁用）有这个负载。 因此，有可能大大减少常规函数的滞后信息的数量（减少调用）。 在50分钟内登录。 2021.03.05 19:31:45.429 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 154 mcs. 2021.03.05 19:32:58.939 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 161 mcs. 2021.03.05 19:33:01.583 ::SymbolInfoTick(_Symbol,Tick)] = 158 mcs. 2021.03.05 19:36:01.682 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 143 mcs. 2021.03.05 19:36:31.229 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 234 mcs. 2021.03.05 19:36:31.229 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 913 mcs. 2021.03.05 19:39:08.716 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 139 mcs. 2021.03.05 19:39:30.994 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 315 mcs. 2021.03.05 19:39:32.858 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 114 mcs. 2021.03.05 19:40:41.437 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 101 mcs. 2021.03.05 19:42:26.104 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 116 mcs. 2021.03.05 19:42:28.849 ::SymbolInfoTick(_Symbol,Tick)] = 109 mcs. 2021.03.05 19:43:10.977 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 481 mcs. 2021.03.05 19:43:53.945 ::SymbolInfoTick(_Symbol,Tick)] = 130 mcs. 2021.03.05 19:49:20.352 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 101 mcs. 2021.03.05 19:51:31.242 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 102 mcs. 2021.03.05 19:51:44.986 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 107 mcs. 2021.03.05 19:52:05.590 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 219 mcs. 2021.03.05 19:53:56.013 ::SymbolInfoTick(_Symbol,Tick)] = 236 mcs. 2021.03.05 19:55:41.453 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 105 mcs. 2021.03.05 19:55:47.109 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 148 mcs. 2021.03.05 19:55:47.110 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 265 mcs. 2021.03.05 19:59:26.011 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 186 mcs. 2021.03.05 20:00:01.569 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 117 mcs. 2021.03.05 20:01:19.704 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 109 mcs. 2021.03.05 20:02:07.285 ::SymbolInfoTick(_Symbol,Tick)] = 177 mcs. 2021.03.05 20:02:07.286 ::SymbolInfoTick(_Symbol,Tick)] = 198 mcs. 2021.03.05 20:02:07.286 ::SymbolInfoTick(_Symbol,Tick)] = 202 mcs. 2021.03.05 20:04:40.170 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 364 mcs. 2021.03.05 20:04:45.905 ::SymbolInfoTick(_Symbol,Tick)] = 143 mcs. 2021.03.05 20:04:45.906 ::SymbolInfoTick(_Symbol,Tick)] = 158 mcs. 2021.03.05 20:04:45.907 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 504 mcs. 2021.03.05 20:04:48.259 ::SymbolInfoTick(_Symbol,Tick)] = 104 mcs. 2021.03.05 20:04:54.727 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 104 mcs. 2021.03.05 20:05:39.642 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 101 mcs. 2021.03.05 20:07:40.189 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 101 mcs. 2021.03.05 20:09:21.844 ::SymbolInfoTick(_Symbol,Tick)] = 115 mcs. 2021.03.05 20:09:32.422 ::SymbolInfoTick(_Symbol,Tick)] = 107 mcs. 2021.03.05 20:10:02.423 ::SymbolInfoTick(_Symbol,Tick)] = 128 mcs. 2021.03.05 20:15:48.838 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 149 mcs. 2021.03.05 20:16:36.001 ::SymbolInfoTick(_Symbol,Tick)] = 105 mcs. 2021.03.05 20:17:51.499 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 480 mcs. 2021.03.05 20:17:51.638 ::SymbolInfoTick(_Symbol,Tick)] = 342 mcs. 2021.03.05 20:17:52.802 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 429 mcs. 2021.03.05 20:17:53.340 ::SymbolInfoTick(_Symbol,Tick)] = 142 mcs. 2021.03.05 20:19:21.512 ::SymbolInfoTick(_Symbol,Tick)] = 122 mcs. 2021.03.05 20:20:35.836 ::CopyTicks(_Symbol,Tick,COPY_TICKS_ALL,0,1)] = 116 mcs. 看起来不是太糟糕。没有任何贸易交易。他们怎么样，我看看。 然而，突出显示的片段显示，三个EA（不同的角色）几乎同时被滞后。也就是说，滞后性对终端来说是普遍的。 fxsaber 2021.03.05 18:58 #887 Slava:Symbol()，_Symbol条目等同于NULL（其中允许用NULL代替符号名）。在这种情况下，不需要额外检查当前符号的存在、当前符号在市场观察中的存在以及当前符号的不必要的调用属性，因为当前节点的属性是被缓存的也就是说，如果你指定一个简单的字符串参数，而不是Symbol()、_Symbol或NULL，那么就会有对完整程序和更多请求属性的检查 请再次解释，因为论坛用户对你的话有不同的解释。 fxsaber 2021.03.05 21:50 #888 在终端，有一个EA/chart/symbol。 2021.03.05 23:02:02.860 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 189 mcs. 2021.03.05 23:02:24.152 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 339 mcs. 2021.03.05 23:02:53.540 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 915 mcs. 2021.03.05 23:05:35.325 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 223 mcs. 2021.03.05 23:05:41.398 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 245 mcs. 2021.03.05 23:05:44.585 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 376 mcs. 2021.03.05 23:06:35.210 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 173 mcs. 2021.03.05 23:07:38.298 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 290 mcs. 2021.03.05 23:08:50.342 ::CopyTicksRange(_Symbol,Ticks,COPY_TICKS_INFO,From)] = 102 mcs. 2021.03.05 23:14:58.216 ::SymbolInfoTick(_Symbol,Tick)] = 447 mcs. 这样的日志在15分钟内完成。似乎毕竟是一个缓慢的Windows的问题。在这种情况下，它是。 2021.03.05 23:49:20.792 Terminal MetaTrader 5 x64 build 2815 started for MetaQuotes Software Corp. 2021.03.05 23:49:20.792 Terminal Windows Server 2019 build 17763, Intel Core i7-7700 K @ 4.20 GHz, 17 / 31 Gb memory, 3698 / 3725 Gb disk, IE 11, RDP, UAC, GMT+2 fxsaber 2021.03.10 13:53 #889 市场观察》造成的刹车的一个明显例子。 看一下处理器一栏中的数值（从右数第二个）。 fxsaber 2021.03.12 10:05 #890 在服务器的 滞后上，再加上终端的滞后。 关于交易、自动交易系统和测试交易策略的论坛 指标：平 fxsaber, 2021.03.12 10:56 只是想起了这个伟大的指标。 这是一张来自零ping的机器的照片。事实证明，终端的内部滞后平均为~2ms。它在0-9毫秒之间跳动。 例如，服务器收到了两个ticks：第一个，然后是10ms后的第二个。因此，在Terminal中，第二个刻度不是在第一个刻度之后的10毫秒内收到，而是在10-19毫秒内。平均而言，在12毫秒内。 如果你从市场上进行交易（市场行情或当前价格的挂单），将特别难以管理。很难说开发商是否能在这里改进什么。 看了一下莫斯科的交易所，那里的情况也差不多。事实上，通过MT5算法进行交易，你几乎可以保证处于执行队列的末端，没有时间去捡好东西，很遗憾。 Акцептирование SL/TP-ордеров 2020.11.24www.mql5.com В этой ветке пойдет речь об ордерах, которые создаются в результате срабатывания SL/TP-уровней открытых позиций... 1...82838485868788899091929394 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
也许只要进行几次测试，问题就会消失？
也许。我希望我有更多的时间来自己做测试 :(
也许只要进行几次测试，问题就会消失？
测试只有在你第一次开始的时候才会显示出差异。
Symbol()，_Symbol条目等同于NULL（其中允许用NULL代替符号名）。
在这种情况下，不需要额外检查当前符号的存在、当前符号在市场观察中的存在以及不必要地调用当前符号的属性，因为当前字符的属性已被缓存。
也就是说，如果指定了一个普通的字符串参数，而不是Symbol()、_Symbol或NULL，那么就检查完整的程序和更多的属性调用
问题。
- 在这两种情况下，SymbolInfoXXX 调用的行为，它们的差异会不会超过一个检查？
?
顺便说一下，从今天最新发布的MT5版本的新鲜日志来看。
这是在一个符号上盘旋的3个EA，每个都在自己的图表上。而这个要求每隔一段时间 就会继续下去。这样的峰值当然不常有，但事实上，1个来自最后一个tick的新ticks请求被执行了700毫秒。
我已经监测了大约12个小时，但我已经可以看到滞后性跨越了所有极限。
3个EA，每个都在自己的图表上，都在1个符号上，都在通过CopyTicksRange请求从前一个tick开始的旧ticks。而滞后的时间几乎为9秒。而且似乎这还不是极限。最有可能的是，Tick存储是一个共享资源，对它的访问是同步的，但即使是非常糟糕的同步，也不应该有这种时间。
有人会说这是一个一次性的小故障。在这12个小时的监测中，不幸的是，已经有超过100个1秒的退出。而这些看起来不再是一次性的突发事件。看起来经常有多个蜱虫同时进入，这就是造成这些尖峰的原因。
即使我们闭上眼睛，不看3个EA为一个共同的资源而争斗的事实，让我们看一下其他的监测。
该符号上只有1个专家顾问。而且还是一秒半。它不是唯一的一个，还有其他符号的EA，但它不是多线程的吗？或者说不同符号的蜱虫仍然可以互相拖累？
这是对基本EA的基本功能。该平台被定位为一个算法交易平台。这就是说，基本功能引起了强烈的质疑。一个很大的要求是再看一下。我几乎可以肯定在某处有改进的余地。或者，如果能像这里建议的那样，获得函数被调用后的最后几秒钟，我将非常感激
关于交易、自动交易系统和测试交易策略的论坛
MT5和速度在行动
fxsaber, 2021.03.01 07:28
请考虑这样的功能。
现在，只有通过CopyTicks*才能解决获得新刻度线而不跳过的问题。对于这项广泛的任务，这是一个非常繁琐的机制。这就像用大炮打鸟。
因此，刹车，保留巨大的缓存，等等。
尽量减少了对SymbolInfoTick和CopyTicksRange的调用。
终端和机器（交换文件被禁用）有这个负载。
因此，有可能大大减少常规函数的滞后信息的数量（减少调用）。
在50分钟内登录。
看起来不是太糟糕。没有任何贸易交易。他们怎么样，我看看。
然而，突出显示的片段显示，三个EA（不同的角色）几乎同时被滞后。也就是说，滞后性对终端来说是普遍的。
Symbol()，_Symbol条目等同于NULL（其中允许用NULL代替符号名）。
在这种情况下，不需要额外检查当前符号的存在、当前符号在市场观察中的存在以及当前符号的不必要的调用属性，因为当前节点的属性是被缓存的
也就是说，如果你指定一个简单的字符串参数，而不是Symbol()、_Symbol或NULL，那么就会有对完整程序和更多请求属性的检查
请再次解释，因为论坛用户对你的话有不同的解释。
在终端，有一个EA/chart/symbol。
这样的日志在15分钟内完成。似乎毕竟是一个缓慢的Windows的问题。在这种情况下，它是。
市场观察》造成的刹车的一个明显例子。
看一下处理器一栏中的数值（从右数第二个）。
关于交易、自动交易系统和测试交易策略的论坛
指标：平
fxsaber, 2021.03.12 10:56
只是想起了这个伟大的指标。
这是一张来自零ping的机器的照片。事实证明，终端的内部滞后平均为~2ms。它在0-9毫秒之间跳动。
例如，服务器收到了两个ticks：第一个，然后是10ms后的第二个。因此，在Terminal中，第二个刻度不是在第一个刻度之后的10毫秒内收到，而是在10-19毫秒内。平均而言，在12毫秒内。
如果你从市场上进行交易（市场行情或当前价格的挂单），将特别难以管理。很难说开发商是否能在这里改进什么。
看了一下莫斯科的交易所，那里的情况也差不多。事实上，通过MT5算法进行交易，你几乎可以保证处于执行队列的末端，没有时间去捡好东西，很遗憾。