MT5和速度在行动 - 页 27

新评论
 
fxsaber:

你认为哪个终端消耗的CPU更多？

2，原因 如下

 
fxsaber:

为了减少CPU，我建议关闭终端的所有子窗口（市场观察、导航仪、工具等），将所有图表最小化，并将终端本身最小化。

从市场观察中删除所有未使用的符号。这对VPS来说尤其重要。


我建议以某种方式将这些行动自动化。在你离开你的VPS之前，请按下并离开。当你进来的时候--记者，你看到了一切。

我已经说了很久，algotraders需要另一个版本的终端，不需要所有这些调整！"。

除了上述所有内容外，我还为每个EA增加了一个新的内容。

ChartSetInteger(0,CHART_SHOW,false);

仍然滞后:(

 
A100:

第2个，这就是原因。

是的，第二个。

 
SymbolInfoTick 是如何架构的？对于为什么它可以运行几十毫秒，人们并不了解。
 

与b2592相比，b2560在性能上有很大的损失。期待修复这个错误。

这条线已经变成了有用的。

 
fxsaber:

与b2592相比，b2560在性能上有很大的损失。等待错误 修复。

b2593已被修复。谢谢你!

 
将订单/交易添加到交易历史中会导致HistorySelect缓存的完全重建，而不是部分重建。因此，我们在触发滞后性方面有滞后性。 
// Демонстрация полного (не частичного) пересбора HistorySelect-кеша.
#include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/321/Benchmark.mqh

input int inAlertTime = 1; // Нижний порог в миллисекундах

#define _B2(A) _B(A, inAlertTime)

const bool Init = EventSetTimer(1);

void OnTimer()
{
  static MqlTradeRequest Request = {0};
  static MqlTradeResult Result = {0};

  if (PositionSelectByTicket(Result.order)) // Если позиция открыта - закрываем.
  {
    Request.type = ORDER_TYPE_SELL;
    Request.price = SymbolInfoDouble(_Symbol, SYMBOL_BID);
    Request.position = Result.order;
  }
  else // Иначе - открываем.
  {
    Request.action = TRADE_ACTION_DEAL;
    Request.type = ORDER_TYPE_BUY;
    Request.symbol = _Symbol;
    Request.volume = 0.1;
    Request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
    Request.position = 0;
  }

  if (OrderSend(Request, Result))
    _B2(HistorySelect(0, INT_MAX));
}

结果。 
2020.09.08 20:23:32.103 Alert: Time[Test6.mq5 411: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:23:32.239 Alert: Time[Test6.mq5 411: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:31:59.863 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 9 ms.
2020.09.08 20:32:00.845 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 5 ms.
2020.09.08 20:32:01.856 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 4 ms.
2020.09.08 20:32:02.846 Alert: Time[Test6.mq5 433: HistorySelect(0,INT_MAX)] = 7 ms.


它为什么重要。让我们想象一下，一个HFT机器人正在运行。在同一个账户上，有一笔交易是用手执行的。就这样，HFT-机器人已经放弃了HistorySelect-cache，并带来了相应的后果。当然，HFT-机器人的历史不是10K订单/交易，而是更多。为这样的历史重建整个缓存将是昂贵的。这就是为什么添加它们是合乎逻辑的。


很明显，人工交易不应该拖累机器人。对于纯粹的算法交易，问题出现在订单被触发的时候。

 

允许对当前交易环境（头寸和订单）进行完整（结构数组）快照的功能非常缺乏。

在循环中传递这两个列表时，通过Position*和Order*函数的变体会导致碰撞（主动交易）。有些东西丢失了，或者没有被说明。

即时完整的快照将避免这些问题。


ZZY 市场观察的全部快照--还没有评估其相关性。使MT5更接近于HFT（LCI）。

 

管理（不是故意的），使终端（和没有）进入CPU为100%，OrderSend等待时间超过一秒的状态。

要找到原因可能并不容易。


ZZY 看来这种刹车是由类似的设计造成的。

void OnTrade()
{
  OnTick();
}

我还没有设法创建任何代码来重现它。


事实上，有可能使终端进入一种状态，即交易订单 将在几秒钟内执行（终端日志），平移量为50毫秒。一旦EA被移除，交易订单就会在100ms内开始执行。

 
fxsaber:

允许对当前交易环境（头寸和订单）进行完整（结构数组）快照的功能非常缺乏。

在循环中传递这两个列表时，通过Position*和Order*函数的变体会导致碰撞（主动交易）。有些东西丢失了，或者没有被说明。

即时完整的快照将避免此类问题。


ZZY 市场观察的全部快照--还没有评估其相关性。使MT5更接近于HFT（LFI）。

还有全时功能，按票据追踪订单-交易-位置，并按票据位置向后追踪，以了解订单的内容和交易的条件。按历史地位追踪是一个邪恶的现实。

完整的点击环境很酷，但显然很昂贵，而且不那么经常需要。虽然在崩溃的市场))))

对我自己来说，我划分了一个秩序和一个命令。一个执行订单 的指令是一个挂单。市场秩序是混乱的。

不要严格按照非专业的意见来判断。

1...202122232425262728293031323334...94
新评论