«Напоминаю также, что торговая система не является системой точного времени,
детальные исследования по latency мы проводим только в случае обоснованных подозрений
в наличии проблемы на нашей стороне, при этом обязательным условием (не наша прихоть,
просто без этих данных реальный аудит маловозможен) является предоставление детальных логов софта,
снятого дампа трафика на момент проблемы и детального описания методики замеров latency на стороне клиента.»
通过查看日志,我得到了同样的印象。它上升到50ms,然后急剧下降到10ms。二级延迟是独立的。
我希望每个人都能像这样给出他们的日志来研究延迟问题。
这里有比真正的衍生品市场交易更多的失误,所以解决方案不会很快(如果有的话)....。
添加
最令人沮丧的是,这些延迟在交易时显示出来,使交易从有利可图变成无利可图。
添加
当然,交易所也在龇牙咧嘴
你好,我有个问题,对于策略测试器来说,它写的是过期订单被完全执行,尽管事实并非如此。
另外,调用 "HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT); "命令,我得到了0。
比如说,tisket=37的订单,见图。我是不是哪里错了?
你好,我有个问题,对于策略测试器来说,它写的是过期订单被完全执行,尽管事实并非如此。
另外,调用 "HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT); "命令,我得到了0。
比如说,tisket=37的订单,见图。我是不是哪里错了?
你好,我有个问题,对于策略测试器来说,它写的是过期订单被完全执行,尽管事实并非如此。
另外,调用 "HistoryOrderGetDouble(ticket, ORDER_VOLUME_CURRENT); "命令,我得到了0。
例如,有tisket=37的订单,见图。 我是不是哪里错了?
你在调用HistoryOrderGetDouble 之前做HistorySelect?
你是否在调用HistoryOrderGetDouble 之前做HistorySelect?
是的,我知道。我在一个循环中运行整个历史。来自Otkritie的演示终端。是的,在图中你可以看到,一切都被执行了(10分)。
尝试HistoryOrderSelect(ticket)
在历史上只会有一个37号订单
尝试HistoryOrderSelect(ticket)
在历史上只会有一个37号订单
如果(HistoryOrderSelect(37))
Print(HistoryOrderGetDouble(37,ORDER_VOLUME_INITIAL),",HistoryOrderGetDouble(37, ORDER_VOLUME_CURRENT))。
写入10个0。
还仔细检查了HistorySelect()和与之相关的一切,一切都在可靠地工作。
现在,当我再看时,过期的选项已经在某处取消了:)。 这是不是我们正在努力解决的服务器问题?
构建1430
构建1430
这就是缺少的东西