2020.07.1623:43:17.088 Trades 'ххххх': modify order #129368930 sell limit 1 GAZR-6.21 at 19830 sl: 0 tp: 0 expiration: day -> 19824, sl: 0 tp: 0 expiration: day placed for execution in22.283 ms
2020.07.1623:43:17.210 Trades 'ххххх': cancel order #129368930 sell limit 1 GAZR-6.21 at 19824 placed for execution in54.168 ms
也许MQ可以花时间 在他的设备上测试客户-服务器链接?
客户端-服务器的结合?
https://www.mql5.com/ru/forum/334269/page5#comment_15537123
有一种怀疑是MKu已经知道了这一点。显然,他们对此无能为力。否则,它早就被修复了。
我怀疑MKU已经知道这件事了。显然,他们对此无能为力。否则他们早就把它修好了。
我认为 这不是那么容易解决的。
问题是,一个订单(待定)很快就会被设定,但
修改和删除它需要很长的时间。
答案是显而易见的。
对 "实时 "订单数据的存储和访问组织得很差。
他们对 "实时 "订单数据的存储和访问组织不力,也就是存储在MT5服务器上的订单。
我不会猜测他们是如何组织存储和获取订单的,但
但要改变它并不容易!
我认为 这不是那么容易解决的。
问题是,一个订单(待定)很快就会被设定,但
修改和删除需要很长的时间。
答案是显而易见的。
对 "实时 "订单数据的存储和访问组织得很差。
它意味着存储在MT5服务器上的订单。
我不会猜测他们是如何组织存储和获取订单的,但
但要改变它并不容易!
我不知道Opener毕竟能不能解决这个问题?
延迟15秒
2485和2350号建筑
自周五(2020年7月10日)起,在公开赛中,出现了一个较慢的
在Bild 2485上设置订单。
2350上也是如此。
是我一个人的问题,还是其他人也有这个问题?
2485和2350号建筑
自周五(2020年7月10日)起,在公开赛中,出现了一个较慢的
在Bild 2485上设置订单。
2350上也是如此。
是我的问题还是其他人的问题?
事实证明,上周五10.07.2020 Otkryvashka更新了MT5软件的网关....。
原来,在10.07.2020星期五,Opener更新了MT5软件的网关....
新的建筑比旧的差吗?
这是可以预期的。
没有人在说什么。
显然,你是唯一用MT5交易的人))
其余的人已经受够了惊喜,或者正在度假村度假))。
新的建筑比旧的差吗?
这是可以预期的。
没有人在说什么。
显然,你是唯一一个用MT5交易的人))。
其余的人已经受够了惊喜,或者正在度假村度假))。
可能是
在正常范围内。
在正常范围内。
每个人的 "规范 "都是不同的。
我的 "常态 "是4-5毫秒,直到星期五,而现在
但这是一个没有Exchange响应的指标,因为MQ不记录异步订单的Exchange响应。
也就是说,它变成了1-1.5秒,而不是8-10毫秒!!。
添加
打开上周四(2020年7月9日)的日志,看看是什么速度...