MT5和速度在行动 - 页 9 12345678910111213141516...94 新评论 Anton 2020.06.04 08:03 #81 fxsaber:原来是经常发生的事情。交易函数没有被调用。SymbolInfoTick有时也是一个不错的滞后。HFT可能对这种意外的滞后非常有经验。请询问开发商,以找到原因。同时,很明显,在战斗中,EA的剖析器是 必须的。 在 "空 "终端上,测试会显示什么? void OnStart() { MqlTick Tick; //--- ulong start,end,max_time=0,avr_time=0; int count=100000; for(int i=0; i<count; i++) { start=GetMicrosecondCount(); SymbolInfoTick(_Symbol, Tick); end=GetMicrosecondCount()-start; //--- >1 ms if(end>1000) Print(" > 1 ms for one SymbolInfoTick: ",DoubleToString(end/1000.0,2)," ms"); //--- if(end>max_time) max_time=end; avr_time+=end; } Print("SymbolInfoTick max time: ",DoubleToString(max_time/1000.0,3)," ms; avr time: ",DoubleToString(avr_time/1000.0/count,3)," ms; ",count," iterations"); //--- start=GetMicrosecondCount(); for(int i=0; i<count; i++) SymbolInfoTick(_Symbol, Tick); end=GetMicrosecondCount()-start; Print(count," SymbolInfoTick = ",DoubleToString(end/1000.0,2)," ms"); } 它应该是这样的。 2020.06.04 11:02:30.123 TestSymbolInfoTick (EURUSD,H1) SymbolInfoTick max time: 0.138 ms; avr time: 0.000 ms; 100000 iterations 2020.06.04 11:02:30.138 TestSymbolInfoTick (EURUSD,H1) 100000 SymbolInfoTick = 14.85 ms 2020.06.04 11:02:31.433 TestSymbolInfoTick (EURUSD,H1) SymbolInfoTick max time: 0.051 ms; avr time: 0.000 ms; 100000 iterations 2020.06.04 11:02:31.448 TestSymbolInfoTick (EURUSD,H1) 100000 SymbolInfoTick = 15.17 ms 2020.06.04 11:02:33.064 TestSymbolInfoTick (EURUSD,H1) SymbolInfoTick max time: 0.035 ms; avr time: 0.000 ms; 100000 iterations 2020.06.04 11:02:33.079 TestSymbolInfoTick (EURUSD,H1) 100000 SymbolInfoTick = 15.12 ms 除非你详细地告诉我们你在做什么,你到底是如何把负荷放在终端上的,否则我们将很难找到原因。 fxsaber 2020.06.04 08:49 #82 Anton:在一个 "空 "终端上,测试会显示什么?它应该是这样的。 SymbolInfoTick max time: 0.034 ms; avr time: 0.000 ms; 100000 iterations 100000 SymbolInfoTick = 8.56 ms SymbolInfoTick max time: 0.047 ms; avr time: 0.000 ms; 100000 iterations 100000 SymbolInfoTick = 9.04 ms SymbolInfoTick max time: 0.045 ms; avr time: 0.000 ms; 100000 iterations 100000 SymbolInfoTick = 9.02 ms 除非你详细告诉我们你在做什么,你到底是如何把负荷放在终端的,否则我们很难找到原因。 10万次迭代并不是一个指标。由于该功能并不总是慢下来,但有时。 事实上,我需要禁用大块的战斗EA,直到制动停止。然后我可以提供代码。我们必须等待。 fxsaber 2020.06.04 09:08 #83 fxsaber:事实上,我需要禁用大块的战斗顾问,直到刹车停止。然后我可以提供代码。我必须等待。 在几个角色上运行这个EA,以获得快速的结果。 #include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/321/Benchmark.mqh void OnTick() { MqlTick Tick[1]; if (_B(CopyTicks(_Symbol, Tick, COPY_TICKS_ALL, 0, 1), 1)) // Не знаю, влияет это или нет. _B(SymbolInfoTick(_Symbol, Tick[0]), 1); } 五分钟就搞定了。 Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 9 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 3 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 4 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 1 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 2 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 5 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 2 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 1 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 16 ms. Alert: Time[Test6.mq5 8: SymbolInfoTick(_Symbol,Tick[0])] = 16 ms. 看来,在EA中只留下这个(没有CopyTicks)就足够了。 _B(SymbolInfoTick(_Symbol, Tick[0]), 1); fxsaber 2020.06.04 11:33 #84 fxsaber:10万次迭代并不是一个指标。由于该功能并不总是慢下来,但有时。 我建议改变定义一个函数的牢度的概念。 如果一个函数的执行时间没有峰值,那么它就是快速的。 如上所示,即使是简单的函数也有这样的峰值。有时是非常大的。我不知道这有什么关系。但是很明显,所有的交易关键功能 都应该用上面建议的方法检查是否存在峰值。也就是说,我们在几个小时内运行并监测大于一毫秒的峰值。 有必要实现至少在一个空的终端上没有峰值。快速的10万次迭代结果是什么都没有。 Alexandr Andreev 2020.06.04 11:49 #85 fxsaber:我建议改变定义一个函数的牢度的概念。如果一个函数的持续时间没有峰值,那么它就是快速的。如上所示,即使是简单的函数也有这样的峰值。有时是非常大的。我不知道这跟它有什么关系。但是很明显,所有的交易关键功能 都应该用上面建议的方法检查是否存在峰值。也就是说,我们在几个小时内运行并监测大于一毫秒的峰值。有必要实现至少在一个空的终端上没有峰值。快速的10万次迭代结果是什么都没有。 有时会出现这样的情况:如果有另一个任务正在运行,那么计时器显示的时间是累计的。例如,在使用画布工作时可能会发生这种情况--当显示函数将任务设置为显示而不创建图像并回来时。之后,任何其他的功能都是按顺序执行的,例如同样的评论,然而画布映射的过程是在CPU语言中开始的,之后才会显示画布。在测量时间时,你可以看到注释需要很长的时间才能输出,但kanvas显示功能的运行时间为0ms。 fxsaber 2020.06.04 12:38 #86 fxsaber:运行并监测超过一毫秒的峰值,持续几个小时。我们需要确保至少在一个空的终端上没有峰值。快速的10万次迭代结果是没有价值的。 我起草了这样一个专家顾问,用于监测。 // Мониторинг длительных пиков выполнения важных функций для торговли. #include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/321/Benchmark.mqh input int inCycle = 10; // Циклов проверки в одном OnTick input int inAlertTime = 1; // Нижний порог в миллисекундах #define _B2(A) _B(A, AlertTime) void Check( const string Symb, const int AlertTime = 1 ) { MqlTick Tick; if (_B2(SymbolInfoTick(Symb, Tick))) { MqlTick Ticks[]; _B2(CopyTicks(Symb, Ticks, COPY_TICKS_ALL, 0, 1)); _B2(CopyTicks(Symb, Ticks, COPY_TICKS_ALL, Tick.time_msc)); _B2(CopyTicksRange(Symb, Ticks, COPY_TICKS_ALL, Tick.time_msc)); _B2(HistorySelect(Tick.time, INT_MAX)); _B2(HistoryDealsTotal()); _B2(HistoryDealGetTicket(0)); _B2(HistoryDealGetInteger(0, DEAL_MAGIC)); _B2(HistoryDealGetDouble(0, DEAL_PRICE)); _B2(HistoryDealSelect(0)); _B2(HistoryOrdersTotal()); _B2(HistoryOrderGetTicket(0)); _B2(HistoryOrderGetInteger(0, ORDER_MAGIC)); _B2(HistoryOrderGetDouble(0, ORDER_PRICE_CURRENT)); _B2(HistoryOrderSelect(0)); _B2(GetLastError()); _B2(IsStopped()); _B2(SymbolInfoDouble(Symb, SYMBOL_ASK)); _B2(SymbolInfoDouble(Symb, SYMBOL_TRADE_TICK_VALUE)); _B2(SymbolInfoDouble(Symb, SYMBOL_POINT)); _B2(SymbolInfoInteger(Symb, SYMBOL_DIGITS)); _B2(TimeCurrent()); _B2(TimeLocal()); _B2(TimeTradeServer()); _B2(OrdersTotal()); _B2(OrderSelect(0)); _B2(OrderGetDouble(ORDER_PRICE_CURRENT)); _B2(OrderGetInteger(ORDER_MAGIC)); _B2(OrderGetString(ORDER_SYMBOL)); _B2(PositionsTotal()); _B2(PositionSelect(Symb)); _B2(PositionSelectByTicket(0)); _B2(PositionGetDouble(POSITION_PRICE_CURRENT)); _B2(PositionGetInteger(POSITION_MAGIC)); _B2(PositionGetString(POSITION_SYMBOL)); _B2(AccountInfoDouble(ACCOUNT_EQUITY)); _B2(AccountInfoInteger(ACCOUNT_MARGIN_MODE)); MqlTradeRequest Request = {0}; MqlTradeCheckResult CheckResult; _B2(OrderCheck(Request, CheckResult)); _B2(MQLInfoInteger(MQL_TRADE_ALLOWED)); _B2(AccountInfoInteger(ACCOUNT_TRADE_EXPERT)); _B2(AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)); _B2(TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)); _B2(SymbolsTotal(true)); _B2(SymbolName(0, true)); _B2(Symbol()); _B2(GlobalVariableCheck(NULL)); _B2(GlobalVariableGet(NULL)); _B2(ResourceFree(NULL)); } } void OnTick() { for (int i = 0; i < inCycle; i++) Check(_Symbol, inAlertTime); } 我在5分钟的监测中得到了结果。 Alert: Time[Test6.mq5 18: HistorySelect(Tick.time,INT_MAX)] = 21 ms. Alert: Time[Test6.mq5 24: HistoryDealSelect(0)] = 4 ms. Alert: Time[Test6.mq5 10: SymbolInfoTick(Symb,Tick)] = 24 ms. Alert: Time[Test6.mq5 14: CopyTicks(Symb,Ticks,COPY_TICKS_ALL,0,1)] = 4 ms. Alert: Time[Test6.mq5 30: HistoryOrderSelect(0)] = 3 ms. Alert: Time[Test6.mq5 35: SymbolInfoDouble(Symb,SYMBOL_ASK)] = 2 ms. SZZY 在这样的输入参数值下,警报会少很多。 input int inAlertTime = 10; // Нижний порог в миллисекундах 但结果也是更重要的。 Alert: Time[Test6.mq5 21: HistorySelect(Tick.time,INT_MAX)] = 19 ms. Alert: Time[Test6.mq5 21: HistorySelect(Tick.time,INT_MAX)] = 10 ms. Alert: Time[Test6.mq5 38: SymbolInfoDouble(Symb,SYMBOL_ASK)] = 10 ms. Alert: Time[Test6.mq5 13: SymbolInfoTick(Symb,Tick)] = 10 ms. Alert: Time[Test6.mq5 38: SymbolInfoDouble(Symb,SYMBOL_ASK)] = 10 ms. Alert: Time[Test6.mq5 17: CopyTicks(Symb,Ticks,COPY_TICKS_ALL,0,1)] = 148 ms. Alert: Time[Test6.mq5 74: SymbolName(0,true)] = 11 ms. fxsaber 2020.06.04 13:08 #87 最后,在我修改一堆订单的情况下,有时每个订单需要3-10秒。之后,它又需要0.1秒的漫长时间。 调出了服务器日志--那里是即时的。 这在战斗的专家顾问上是非常不愉快的。 2020.06.04 15:24:48.771 Alert: Time[NewTicks.mqh 31: ::SymbolInfoTick(_Symbol,Tick)] = 61 ms. 2020.06.04 15:25:21.729 Alert: Time[NewTicks.mqh 31: ::SymbolInfoTick(_Symbol,Tick)] = 29 ms. 2020.06.04 15:27:57.842 Alert: Time[NewTicks.mqh 31: ::SymbolInfoTick(_Symbol,Tick)] = 142 ms. 一些奇妙的价值。 fxsaber 2020.06.10 14:45 #88 fxsaber:最后,在我修改一堆订单的情况下,有时每个订单需要3-10秒。此后,它又需要0.1秒的漫长时间。提出了服务器日志--马上就有了。 这种情况在另一个交易服务器上重复出现。 终端修改开放位置需要2.5秒。在服务器上 - 2毫秒。 最有可能的是,这也是FORTS-执行 的问题的来源。 ФОРТС. Вопросы по исполнению 2020.03.30www.mql5.com С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,. fxsaber 2020.06.11 21:11 #89 重新传送。 关于交易、自动交易系统和交易策略测试的论坛 MetaTrader 5 build 1700平台测试版:MetaEditor和合成工具的项目 Renat Fatkhullin, 2017.12.14 12:47 这是一个衡量沟通质量的指标。TCP/IP协议中重传的网络数据包的百分比。 它是在网络接口层面对整个操作系统的所有应用程序进行全局计算。当你怀疑速度慢和问题时,看看这个指标。当经纪人的服务器离得很远时,这一点至关重要。例如,对于亚洲的交易者和欧洲的经纪人。 已经有3%的重传率,你可以告诉你不能交易。重 传的极端水平是由坏的WIFI给出的。 关于交易、自动交易系统和交易策略测试的论坛 新版MetaTrader 5 build 2360:扩大与SQLite的整合范围 Renat Fatkhullin, 2020.04.06 12:33 正常情况下,应该低于1%。而3%的网络损失已经扼杀了低延迟的服务。 例如,我们的重传是0.68 - 0.75%,用户明显更多(我们在MetaQuotes-Demo上有17000个在线用户)。而且我们为整个世界服务,而不是为莫斯科/俄罗斯服务。 关于交易、自动交易系统和交易策略测试的论坛 虫子、虫子、问题 fxsaber, 2017.12.17 22:43 关于交易、自动交易系统和交易策略测试的论坛 虫子、虫子、问题 Renat Fatkhullin, 2017.12.17 23:03 这些是整个计算机的网络接口的统计数据,其中Metatrader只是其中一个用户。它不一定与交易服务器有关。 一般的统计资料很容易被网络浏览器在访问一些故障和遥远的网站时损坏。本地WIFI也有可能抓住网络冲突,在随机的时间点上得到百分之几十的重传。 在20%重传的情况下,将没有与交易服务器的连接,重连将是持续和无休止的。终端有持续的连接,即使是3-5%的重传也会对它保持长时间的连接造成致命的影响。 关于交易、自动交易系统和交易策略测试的论坛 虫子、虫子、问题 Renat Fatkhullin, 2017.12.18 11:36 请记住,这是一个由操作系统报告的本地 TCP/IP堆栈的技术特征,而不是与交易服务器的特定连接质量的指标。它包括所有网络活动,包括系统/电话活动。 众所周知,交易集群的连接是高质量的,我们记录了大量的参数(这是一个标准的平台功能),收集一分钟的快照和后续分析。 关于交易、自动交易系统和交易策略测试的论坛 虫子、虫子、问题 Renat Fatkhullin, 2017.12.18 00:13 已检查。 在我们的演示集群中,没有一个节点,包括亚洲,在整个一天中(以及在其他日子里)有任何重新启动或重传水平的提高。一切都在0.5%和1.5%之间,是正常的。 我似乎有很多。 现在是午夜了,报价器很少更新。转发量在我眼前不断增加。我想把VPS上的Alert调到一个高值>1%,以实现低延迟交易。但在如此巨大的价值下,这种想法变得毫无意义。 我可以推荐什么?追踪到交易服务器吗?某种监测计划?一般来说,如何确保MT5为低延迟做好准备? ZS 只要报价开始加快,指数就会下降很多倍。 MT5 and speed in 时间序列挖掘的数据标签(第2部分):使用Python制作带有趋势标记的数据集 SQLite: MQL5 原生 SQL Edgar Akhmadeev 2020.06.12 02:59 #90 fxsaber:转发者。 我似乎有很多这样的东西。 早上5-6点。 家庭(光纤,ETH到路由器,电缆到电脑) - 8-19%,ping 60-70 荷兰的VPS(目前有1个MT5,9个货币/11图表) - 1.2-1.6%,ping 3.7 12345678910111213141516...94 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
原来是经常发生的事情。交易函数没有被调用。
SymbolInfoTick有时也是一个不错的滞后。HFT可能对这种意外的滞后非常有经验。
请询问开发商,以找到原因。同时,很明显,在战斗中,EA的剖析器是 必须的。
在 "空 "终端上,测试会显示什么?
它应该是这样的。
除非你详细地告诉我们你在做什么,你到底是如何把负荷放在终端上的,否则我们将很难找到原因。
在一个 "空 "终端上,测试会显示什么?
它应该是这样的。
除非你详细告诉我们你在做什么,你到底是如何把负荷放在终端的,否则我们很难找到原因。
10万次迭代并不是一个指标。由于该功能并不总是慢下来,但有时。
事实上,我需要禁用大块的战斗EA,直到制动停止。然后我可以提供代码。我们必须等待。
事实上,我需要禁用大块的战斗顾问,直到刹车停止。然后我可以提供代码。我必须等待。
在几个角色上运行这个EA,以获得快速的结果。
五分钟就搞定了。
看来,在EA中只留下这个(没有CopyTicks)就足够了。
10万次迭代并不是一个指标。由于该功能并不总是慢下来,但有时。
我建议改变定义一个函数的牢度的概念。
如果一个函数的执行时间没有峰值,那么它就是快速的。
如上所示,即使是简单的函数也有这样的峰值。有时是非常大的。我不知道这有什么关系。但是很明显,所有的交易关键功能 都应该用上面建议的方法检查是否存在峰值。也就是说,我们在几个小时内运行并监测大于一毫秒的峰值。
有必要实现至少在一个空的终端上没有峰值。快速的10万次迭代结果是什么都没有。
我建议改变定义一个函数的牢度的概念。
如果一个函数的持续时间没有峰值,那么它就是快速的。
如上所示,即使是简单的函数也有这样的峰值。有时是非常大的。我不知道这跟它有什么关系。但是很明显,所有的交易关键功能 都应该用上面建议的方法检查是否存在峰值。也就是说,我们在几个小时内运行并监测大于一毫秒的峰值。
有必要实现至少在一个空的终端上没有峰值。快速的10万次迭代结果是什么都没有。
有时会出现这样的情况:如果有另一个任务正在运行,那么计时器显示的时间是累计的。例如,在使用画布工作时可能会发生这种情况--当显示函数将任务设置为显示而不创建图像并回来时。之后,任何其他的功能都是按顺序执行的,例如同样的评论,然而画布映射的过程是在CPU语言中开始的,之后才会显示画布。在测量时间时,你可以看到注释需要很长的时间才能输出,但kanvas显示功能的运行时间为0ms。
运行并监测超过一毫秒的峰值,持续几个小时。
我们需要确保至少在一个空的终端上没有峰值。快速的10万次迭代结果是没有价值的。
我起草了这样一个专家顾问,用于监测。
我在5分钟的监测中得到了结果。
SZZY 在这样的输入参数值下,警报会少很多。
但结果也是更重要的。
最后,在我修改一堆订单的情况下,有时每个订单需要3-10秒。之后,它又需要0.1秒的漫长时间。
调出了服务器日志--那里是即时的。
这在战斗的专家顾问上是非常不愉快的。
一些奇妙的价值。
最后,在我修改一堆订单的情况下,有时每个订单需要3-10秒。此后,它又需要0.1秒的漫长时间。
提出了服务器日志--马上就有了。
这种情况在另一个交易服务器上重复出现。
终端修改开放位置需要2.5秒。在服务器上 - 2毫秒。
最有可能的是,这也是FORTS-执行 的问题的来源。
重新传送。
关于交易、自动交易系统和交易策略测试的论坛
MetaTrader 5 build 1700平台测试版:MetaEditor和合成工具的项目
Renat Fatkhullin, 2017.12.14 12:47
这是一个衡量沟通质量的指标。TCP/IP协议中重传的网络数据包的百分比。
它是在网络接口层面对整个操作系统的所有应用程序进行全局计算。当你怀疑速度慢和问题时,看看这个指标。当经纪人的服务器离得很远时,这一点至关重要。例如,对于亚洲的交易者和欧洲的经纪人。
已经有3%的重传率,你可以告诉你不能交易。重 传的极端水平是由坏的WIFI给出的。
关于交易、自动交易系统和交易策略测试的论坛
新版MetaTrader 5 build 2360:扩大与SQLite的整合范围
Renat Fatkhullin, 2020.04.06 12:33
正常情况下,应该低于1%。而3%的网络损失已经扼杀了低延迟的服务。
例如,我们的重传是0.68 - 0.75%,用户明显更多(我们在MetaQuotes-Demo上有17000个在线用户)。而且我们为整个世界服务,而不是为莫斯科/俄罗斯服务。
关于交易、自动交易系统和交易策略测试的论坛
虫子、虫子、问题
fxsaber, 2017.12.17 22:43
关于交易、自动交易系统和交易策略测试的论坛
虫子、虫子、问题
Renat Fatkhullin, 2017.12.17 23:03
这些是整个计算机的网络接口的统计数据,其中Metatrader只是其中一个用户。它不一定与交易服务器有关。
一般的统计资料很容易被网络浏览器在访问一些故障和遥远的网站时损坏。本地WIFI也有可能抓住网络冲突,在随机的时间点上得到百分之几十的重传。
在20%重传的情况下,将没有与交易服务器的连接,重连将是持续和无休止的。终端有持续的连接,即使是3-5%的重传也会对它保持长时间的连接造成致命的影响。
关于交易、自动交易系统和交易策略测试的论坛
虫子、虫子、问题
Renat Fatkhullin, 2017.12.18 11:36
请记住,这是一个由操作系统报告的本地 TCP/IP堆栈的技术特征,而不是与交易服务器的特定连接质量的指标。它包括所有网络活动,包括系统/电话活动。
众所周知,交易集群的连接是高质量的,我们记录了大量的参数(这是一个标准的平台功能),收集一分钟的快照和后续分析。
关于交易、自动交易系统和交易策略测试的论坛
虫子、虫子、问题
Renat Fatkhullin, 2017.12.18 00:13
已检查。
在我们的演示集群中,没有一个节点,包括亚洲,在整个一天中(以及在其他日子里)有任何重新启动或重传水平的提高。一切都在0.5%和1.5%之间,是正常的。
我似乎有很多。
现在是午夜了,报价器很少更新。转发量在我眼前不断增加。我想把VPS上的Alert调到一个高值>1%,以实现低延迟交易。但在如此巨大的价值下,这种想法变得毫无意义。
我可以推荐什么?追踪到交易服务器吗?某种监测计划?一般来说,如何确保MT5为低延迟做好准备?
ZS 只要报价开始加快,指数就会下降很多倍。
转发者。
我似乎有很多这样的东西。
早上5-6点。
家庭(光纤,ETH到路由器,电缆到电脑) - 8-19%,ping 60-70
荷兰的VPS(目前有1个MT5,9个货币/11图表) - 1.2-1.6%,ping 3.7