MT5和速度在行动 - 页 44

新评论
 
fxsaber:

我不止一次看到过这样的情况：终端对CPU的负载率高达100%，以至于它对任何事情都没有反应。

然后我看了看日志，发现在OnTick中出现了狂跳的ticks。然而，如果我正确地编写一个EA，这种灾难性的情况不会影响交易结果。我具体分析了一下，一切都很清楚。

我想知道处理市场产品延误的机制有多普遍。我从未见过任何一次提到机器功率的运行。最小的ping是一个yes。

你在哪里发射它们？

如果在 2-5美元的VPS上，那么几十和几百毫秒的延迟在任何几乎不严肃的WinAPI功能中都很容易被发现。一切都从管理程序层面开始变慢，把虚拟机变成了一个幻灯片。

上面已经解释过了。

 
Renat Fatkhullin:

不是GetMicrosecondsCount变慢了，而是操作系统在为你被扼杀的VPS中的任何线程量化CPU资源。对于你的UPU内部的任何功能、任何行动、任何程序。

好吧，当CPU外壳有20个（这还是可敬的）操作系统，每个副本有1500个执行线程时，没有一个CPU外壳可以公平地切分和分配资源。以8-16个核心为例，将它们分布在20*1,500=30,000（三万个物理轨道）。

在我的情况下（虚拟盒，vin7+2核+16GB内存，完全是我自己的硬件，没有其他运行），周期性的2-3µs来自哪里？

关于交易、自动交易系统和交易策略测试的论坛

MT5和战斗中的速度

Andrey Khatimlianskii, 2020.10.05 10:19

不是真正的UPU，而是租用硬件上的虚拟机。

2020.09.29 00:11:11.350 Terminal        MetaTrader 5 x64 build 2615 started for MetaQuotes Software Corp.
2020.09.29 00:11:11.352 Terminal        Windows 7 Service Pack 1 build 7601 on Virtual Box, Intel Core i7-4770  @ 3.40 GHz, 14 / 15 Gb memory, 4 / 31 Gb disk, IE 11, Admin, GMT+2

2020.10.05 11:11:25.340 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:11:31.308 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:12:34.699 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 3 mсs.
2020.10.05 11:13:04.388 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:13:58.116 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:08.388 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:14.975 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:14:19.095 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:28.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:55.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:15:56.814 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:16:27.818 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 9 mсs.
2020.10.05 11:16:35.275 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:16:45.775 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 27 mсs.
2020.10.05 11:16:51.715 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.
2020.10.05 11:17:30.477 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 5 mсs.
2020.10.05 11:18:25.081 test (GBPUSD,M15)       Alert: Time[test.mq5 7 in OnTimer: GetMicrosecondCount()] = 2 mсs.

 
Andrey Khatimlianskii:

在我的情况下（虚拟盒，win7+2个核心+16GB内存，在自己的硬件上，没有其他 东西在旋转），周期性的2-3µs是怎么来的？

这就是双重虚拟化的代价。

特别是由于VirtualBox不是一个成熟的Hyper-V类型的管理程序，而是生活在你目前的桌面操作系统 （Windows 7也是吗）之上，它有一个CPU外壳的地面，用于不同的使用情况。

因此，你有：Windows 7/10 -> VirtualBox -> Windows 7.本质上，两个层次的虚拟化，第一个层次不知道VirtualBox的愿望，把它看作是一个普通的程序。CPU资源分配（线程调度器）显然被搞砸了。

应该是这样。Hyper-V 2016/2019 -> Windows 2016/2019

 
Renat Fatkhullin:

不是GetMicrosecondsCount变慢了，而是操作系统在为你被扼杀的VPS中的任何线程量化CPU资源。对于你的UPU内的任何功能、任何行动、任何程序。

我想这样的争论会让你思考。顾问。

#include <fxsaber\Benchmark\Benchmark.mqh> // https://www.mql5.com/ru/code/31279

// Сделал действия по этой ссылке: https://www.mql5.com/ru/forum/342090/page41#comment_18597040

void OnStart()
{
  _BV(
  for (int i = 0; i < 1 e6; i++)
    GetMicrosecondCount();
      , 1)
      
  _BV(
  for (int i = 0; i < 1 e6; i++)
    GetTickCount();
      , 1)      
}



2020.10.06 00:24:26.779 Alert: Time[Test6.mq5 52: for(inti=0;i<1 e6;i++)GetMicrosecondCount();] = 16289902 mсs.
2020.10.06 00:24:26.784 Alert: Time[Test6.mq5 57: for(inti=0;i<1 e6;i++)GetTickCount();] = 4300 mсs.


到目前为止，还没有让一切都慢下来。这就是为什么我能够很无害地改成winmm::timeBeginPeriod(1)+winmm::timeGetTime()，得到像GetTickCount那样的速度，但没有可怕的16ms限制。然而，市场生产者不允许这样做，因为它是一个DLL。你不太可能做一个毫秒级的普通版本。

 
Renat Fatkhullin:

将所有窗口和应用程序本身最小化的MQL5功能是个好主意。我们将在这方面进行努力。

这里还有一件事。

在VPS上 运行自己的终端，那么他将强烈反对一切突然翻转。如果他离开RDP会话，他可以而且应该自己最小化窗口。

我目前正在使用WinAPI来通过热键最小化。非常方便，比标准的TerminalClose更无害。
 
Renat Fatkhullin:


以下是我想说的一个例子。
两个服务器都是不同的经纪公司，都在同一个地区，可能在同一个地方。
该服务卡建议AMP位于英国。
而且，由于某些原因，在荷兰提供的服务。
为什么？如果有一个更接近的vpc。

dfgh

jt

 
fxsaber:

我想你会发现这是个能让你思考的论点。辅导员。


到目前为止，还没有减缓事情的发展。这就是为什么我能够很无害地改成winmm::timeBeginPeriod(1)+winmm::timeGetTime()，获得像GetTickCount那样的速度，但没有可怕的16ms限制。然而，市场生产者不允许这样做，因为它是一个DLL。你不太可能做一个毫秒级的常规版本。

好吧，你是一个没有关联性或合理性控制的赛车压力测试的大师。

当然，微秒计量需要资源，能够测量比一毫秒小1000倍的间隔。

如果你偶尔 需要超级精确地测量间隔，那么就使用微秒。而这将花费你0微秒的时间。

如果你被设定为将数百万次称为自我测量，你可能是在进行自我欺骗。


在一个被扼杀的VPS上，通过timeBeginPeriod超频系统定时器 是有风险的。你只会增加你的CPU开销。

这个功能会影响一个全局的Windows设置。Windows使用任何进程所要求的最低值（即最高分辨率）。设置一个较高的分辨率可以提高等待功能中超时间隔的准确性。然而，这也会降低系统的整体性能，因为线程调度器更频繁地切换任务。高分辨率也会阻止CPU电源管理系统进入省电模式。设置一个更高的分辨率并不能提高高分辨率性能计数器的精度。

否则，操作系统早就应该做出精确的GetTickCount/GetTickCount64，并为自由的精确性而欢欣鼓舞。但是没有，你必须为这个计时器的准确性付费。

 
请删除CHART_IS_MAXIMIZED 刹车。现在，WinAPI解决方案的速度比原版解决方案快了不是一个数量级。
 
Roman:

以下是我想说的一个例子。
两个服务器都来自不同的经纪公司，都在同一地区，可能在同一地点。
该服务卡建议AMP位于英国。
而且，由于某些原因，在荷兰提供的服务。
为什么？如果有一个PSTN更接近。

我们知道服务器的地理点，这里的经纪人服务器的位置是以GeoIP为基础建立的。

而且经常发生的情况是，这些信息与现实不相符合。因此，我们决不应假定经纪人的立场是准确的。

我们明天会更详细地研究这个问题，因为我们需要手动反复检查和重新扫描所有的东西来回答这个问题。

 
Renat Fatkhullin:

这就是双重虚拟化的代价。

特别是由于VirtualBox不是一个完整的Hyper-V类型的管理程序，而是生活在你目前的桌面操作系统 之上（Windows 7也是？

因此，你有：Windows 7/10 -> VirtualBox -> Windows 7.本质上，两个层次的虚拟化，第一个层次不知道VirtualBox的愿望，把它看作是一个普通的程序。CPU资源分配（线程调度器）显然被搞砸了。

应该是这样。Hyper-V 2016/2019 -> Windows 2016/2019

不，我的CentOS上有虚拟机在旋转。但我没有能力继续这种对话。

1...373839404142434445464748495051...94
新评论