堡垒。执法问题
在过去的几个月里，我从外面看了这个马戏团的一些情况。
为什么所有的问题都交给开发人员，而他们甚至不能进入经纪人的交易服务器？
来自Otkritie的先生们，如果你们正在推出一项新的服务，也许你们会开始回答客户的 问题？还是说你的作用只是用 "下一步 "按钮安装MT服务器，然后从客户机上取走佣金？
我稍后会回复一下细节。
米卡拉斯是对的，特别感谢他的证据基础。正如我所承诺的那样，我们已经在最新的版本中改进了延迟，正在等待所有经纪人的更新。
Discovery尚未将真实服务器更新到1035版本，仍在测试服务器上测试新版本。
我稍后会回复一下细节。
米卡拉斯是对的，特别感谢他的证据基础。正如我所承诺的那样，我们已经在最新的版本中改进了延迟，正在等待所有经纪人的更新。
Discovery尚未将真实服务器更新到1035版本，仍在测试服务器上测试新版本。
Discovery刚刚向演示服务器上传了一个新的Build 1035。
延误减少了2.2倍!
做得好！MQ
现在，我们必须等待新的建设的真实性!
一勺焦油--还是几十毫秒。这些宝贵的时间都花在什么地方了！？
交易所处理的是订单流，以数量级计。而且它在微秒内处理。怎么说呢？
即使是用Java编写的LMAX，其延迟也在2-3ms左右。
一勺焦油--还是几十毫秒。这些宝贵的时间都花在什么地方了！？
交易所处理的是订单流，以数量级计。而且它在微秒内处理。怎么说呢？
即使是用Java编写的LMAX也有~2-3ms的延迟。
从你的计算机到MQ服务器做一个tracert。
你会看到你的互联网消耗了多少延迟。
记住将你的结果乘以2（往返）。
对于我的互联网来说，~42毫秒。
从你的计算机到MQ服务器做一个tracert。
~ 42 ms。你是在谈论整个客户旅程，还是在谈论单个引擎内的 微秒？
人们总是混淆独立引擎排队的时间（高兴地相信关于微秒的故事）和整个网络 到最终零售客户的所有累积网络成本。而在进行比较时，他们也没有注意到，他们抛开了整个环节（ 例如零售业的经纪人中间环节），就像LMAX的情况一样（只比较了直接连接的一个环节）。
让我们清楚和透明。让我们来谈谈延迟减去节点之间的所有 平移。
俄罗斯交易所的HFT人员向我展示了~1ms的延迟。我不是一个技术人员，不能告诉你他们是如何实现的。
同样，在LMAX上的延迟是~2-3ms。
再一次，我们谈论的是零售延迟减去所有平移。
MT5基础设施直接连接到交易所。或者，如你所说，它只是一个 "管道"。HFTs连接他们的管道，得到你上面写的结果。
连接MT5管道会导致时间成本大大增加。原因何在？
下午好，Renat!
在 "FORTS在下订单时出现大的延迟 "的主题中。
你说，你的服务器没有额外的延迟。
你的服务器上没有任何延迟，建议安装一个离它更近的服务器。
在遇到很多问题的情况下，我成功地做到了（Otkrytie有限公司专业客户部负责人）。
说我被分配的虚拟机与你的服务器在同一个机架上）。
与机器连接。
安装了MT-5
然后 "手工挑选"--删除订单，得到了结果。
好吧，我认为这些数据包是通过互联网 "进行 "的。
试图对服务器进行追踪。
服务器和虚拟机之间的延迟小于1毫秒。
同样的结果，当追踪另一个服务器时(87.......)
你如何评论上述情况？