堡垒。执法问题 - 页 5

[kond777]

Papaklass 和Olyakish 先生!

不清楚为什么你在这个重要的话题上开始了个人通信，在雷纳特确认存在

"对终端的回复速度存在浮动误差。

他还承诺，MQ将改善整个订单执行流量。

而且，无论如何，你怎么能在外汇市场的厨房里检查任何东西呢？

[Mikhail Filimonov]

papaklass:

事实上，我们已经发布了很多有用的信息。

- 他们的服务器配置。

- 网络检查方法（ping -t）。

-olyakish 已经发布了他关于选择虚拟服务器的工作。

但看起来你不需要它。

在外汇中，有很多东西都是可以测试的。如果你认为交易所没有操纵行为，那么我很同情你。:)

[Mikhail Filimonov]

kond777:

Papaklass 和Olyakish 先生!

不清楚为什么你在这个重要的话题上开始了个人通信，在雷纳特确认存在

"对终端的回复速度存在浮动误差。

他还承诺，MQ将改善整体订单执行流量。

而且，无论如何，你怎么能在外汇市场的厨房里检查任何东西呢？

[Alexey Klenov]

RE      0       15:30:57.591    Trades  '871788': market buy 0.03 EURUSD.e
JM      0       15:30:57.591    Trades  '871788': market buy 0.04 USDJPY.e
EK      0       15:30:57.591    Trades  '871788': market sell 0.03 EURJPY.e
JS      0       15:30:57.607    Trades  '871788': order #23947599 buy 0.03 / 0.03 EURUSD.e at 1.21874 done in 28 ms
CS      0       15:30:57.607    Trades  '871788': deal #16364222 buy 0.03 EURUSD.e at 1.21874 done (based on order #23947599)
KL      0       15:30:57.622    Trades  '871788': order #23947600 buy 0.04 / 0.04 USDJPY.e at 120.314 done in 44 ms
NF      0       15:30:57.622    Trades  '871788': deal #16364223 buy 0.04 USDJPY.e at 120.314 done (based on order #23947600)
GF      0       15:30:57.653    Trades  '871788': order #23947601 sell 0.03 / 0.03 EURJPY.e at 146.615 done in 74 ms
EF      0       15:30:57.653    Trades  '871788': deal #16364224 sell 0.03 EURJPY.e at 146.615 done (based on order #23947601)
NM      0       15:31:56.771    Trades  '871788': market buy 0.03 EURUSD.e
FD      0       15:31:56.771    Trades  '871788': market buy 0.04 USDJPY.e
IS      0       15:31:56.771    Trades  '871788': market sell 0.03 EURJPY.e
LK      0       15:31:56.803    Trades  '871788': order #23947606 buy 0.03 / 0.03 EURUSD.e at 1.21877 done in 33 ms
RJ      0       15:31:56.803    Trades  '871788': deal #16364229 buy 0.03 EURUSD.e at 1.21877 done (based on order #23947606)
PE      0       15:31:56.834    Trades  '871788': order #23947607 buy 0.04 / 0.04 USDJPY.e at 120.315 done in 64 ms
CO      0       15:31:56.834    Trades  '871788': order #23947608 sell 0.03 / 0.03 EURJPY.e at 146.619 done in 63 ms
OR      0       15:31:56.834    Trades  '871788': deal #16364230 buy 0.04 USDJPY.e at 120.315 done (based on order #23947607)
GO      0       15:31:56.834    Trades  '871788': deal #16364231 sell 0.03 EURJPY.e at 146.619 done (based on order #23947608)
ED      0       15:33:00.526    Trades  '871788': market buy 0.03 EURUSD.e
ML      0       15:33:00.526    Trades  '871788': market buy 0.04 USDJPY.e
RH      0       15:33:00.526    Trades  '871788': market sell 0.03 EURJPY.e
DP      0       15:33:00.526    Trades  '871788': order #23947612 buy 0.03 / 0.03 EURUSD.e at 1.21878 done in 10 ms
OO      0       15:33:00.526    Trades  '871788': order #23947613 buy 0.04 / 0.04 USDJPY.e at 120.315 done in 10 ms
OG      0       15:33:00.526    Trades  '871788': deal #16364236 buy 0.03 EURUSD.e at 1.21878 done (based on order #23947612)
NE      0       15:33:00.526    Trades  '871788': deal #16364237 buy 0.04 USDJPY.e at 120.315 done (based on order #23947613)
LI      0       15:33:00.558    Trades  '871788': order #23947614 sell 0.03 / 0.03 EURJPY.e at 146.612 done in 40 ms
HG      0       15:33:00.558    Trades  '871788': deal #16364238 sell 0.03 EURJPY.e at 146.612 done (based on order #23947614)

这里是API .NET的真实LMAX。

在新闻上的性能是12ms，8ms ping（使用高频定时器测量）。

我想这是一个基准

[Mikhail Filimonov]

olyakish:

这里是API .NET的真实LMAX。

新闻上的性能是12ms，ping为8ms（使用高频计时器测量）。

我想这是一个基准

[Anton]

papaklass:

在最后一批中，你有订单发送，服务器在1（！！）ms内收到回复。而日志显示服务器处理时间为10ms。令人惊叹。:)

问题出现了。

终端日志中公布的计时器是否可信？

目前，日志中时间的准确性取决于系统定时器的 分辨率。在这种情况下，可能是16ms左右（你可以用clockres工具检查）。我们也在努力解决这个问题，日志将得到改进。

[Alexey Klenov]

papaklass:

在最后一批中，你有订单发送，服务器在1（！！）ms内收到回复。而日志显示服务器处理时间为10ms。令人惊叹。:)

问题出现了。

终端日志中公布的计时器是否可信？

这些可能正是离散的16ms。

15:33:00.526 

而这些可能更准确

done in 10 ms

[[删除]]

olyakish:

这里是API .NET的真实LMAX。

在新闻上的执行时间是12毫秒，8毫秒平移（使用高频计时器测量）。

我想这就是准则。

zaskok。

让我们清楚和透明。让我们来谈谈延迟减去节点之间的所有 平移。

俄罗斯交易所的HFT人员向我展示了~1ms的延迟。我不是一个技术人员，不能告诉你他们是如何实现的。

同样，在LMAX上的延迟是~2-3ms。

再一次，我们谈论的是零售延迟减去所有平移。

MT5基础设施直接连接到交易所。或者，如你所说，它只是一个 "管道"。HFTs连接他们的管道，得到你上面写的结果。

连接MT5管道会导致时间成本大大增加。原因何在？

雷纳特。

你不必清楚，但要在专业的知识水平上。

olyakish，你确定你有足够的专业知识水平吗？

[Mikhail Filimonov]

papaklass:

建于1036年。

你是如何处理的呢？执行方面的差异是巨大的。

是否有可能在服务器上实现性能的稳定？

PS：把MT宣传成一个高频平台，看起来多么不合适。:(

纸杯!

没有必要如此 "激动"！这是对的。

你甚至不屑于阅读这些帖子!

并愚蠢地雕刻你的帖子!

你不觉得是时候停下来了吗？

工作人士!!!!

[Mikhail Filimonov]

papaklass:
你能给我看看我应该读的信息吗？

引用雷娜特的话。

Otkritie的1035服务器今天已经开始运行。

下面是莫斯科的VPS（同一台电脑，同一真实账户）的订单触发时间的变化。

2014.12.18 билд 1010 сервера
2014.12.18 10:22:33.885 Trades  'XXXXXX': buy limit 1.00 Si-3.15 at 64638 placed for execution in 72 ms
2014.12.18 10:35:05.309 Trades  'XXXXXX': exchange buy 1.00 Si-3.15 at market placed for execution in 94 ms
2014.12.18 10:35:18.937 Trades  'XXXXXX': exchange sell 1.00 Si-3.15 at market placed for execution in 148 ms

2014.12.24 билд 1035    
2014.12.24 16:06:14.726 Trades  'XXXXXX': sell limit 1.00 Si-3.15 at 58837 placed for execution in 33 ms
2014.12.24 16:08:32.755 Trades  'XXXXXX': exchange sell 1.00 Si-3.15 at market placed for execution in 24 ms
2014.12.24 16:08:46.841 Trades  'XXXXXX': exchange buy 1.00 Si-3.15 at market placed for execution in 26 ms

如同承诺的那样，订单处理速度有了质的（多次）提高。

偶尔出现的响应交付到终端的浮动时间还没有消除，我们将继续努力。

-------------------------------------------------------

而为什么你认为它们是内部的？

1）在OnTradeTransaction中查看你得到多少关于订单的中间状态。

每个交易不是一个数据包（请求-回应），而是几个通知。这是为了让终端始终知道请求处于什么阶段（例如，执行可能需要很长的时间）。

我们现在正在考虑是否有可能在MQL5中加入一个单独的功能，以禁用所有的中间状态通知，将该计划变成一个简单的表格。这可以加快执行速度。

2）你完全忽略了与交易所沟通的第二方面，以及执行速度的可变性。显然，你认为有一个已知的0，但那里不能保证速度。

在我看来，这似乎比它可能的要多出10倍左右。

没有必要因为看了一块伸出水面的阿斯伯格而被欺骗。

让我澄清一下，我们实际上并没有将速度提高2倍，而是获得了大约20-30毫秒。2不是1的两倍，而只是1的倍数。这只是一个低基数效应。

无论如何，我们继续努力，将获得更好的结果。