 本期 延迟，永恒不变的话题，高频交易的函谷关---咽喉要地，兵家必争之地。但是交易市场是一个信息不对称的市场，延迟发生在一系列的交易过程中。就如带兵打仗。不仅要关注兵器是否锋利，士兵是否经过训练？粮草是否充足？盔甲是否坚固等等，都有可能影响战争的胜负与否。  交 易 之 路 交易之路仿佛是盲人摸象，市场的不同参与者只能摸到其中的一部分。那么对于交易延迟的焦点，不同的参与者关注的点自然也就不同。从交易所到经纪公司再到交易者，中间连接着各个系统、网络、服务器、网卡。每个节点都会产生数据传输延迟。如果仅关注可以摸到的部分，那么永远无法知道大象到底长什么样子。 交易延迟的精细化管理，就如大战前将军对军队的部署。知己知彼百战不殆，在了解自己策略的同时，也要去关注外部系统对于交易延迟带来的影响。当然，外部系统包含整个交易路径上的一切软件系统与硬件系统。比如有些策略开发人员，将全部的精力都放在了优化策略、优化程序上面，往往容易忽略了策略程序本身对策略服务器资源消耗或者说资源分配的问题。当部署了多策略时发生策略间互相抢占资源导致影响交易延迟的问题。再如我以前在交流会议等公共演讲所提到的linux的numa架构，很多人策略绑定了cpu核心，但是没有关注内存分配问题，同样的会产生大延迟。 今天我们要讲的是关于经纪商（期货公司）快速柜台系统的延迟问题。对于大部分行业人员来说，这个也许是一个很大的黑盒子。那么我们通过下面对柜台系统延迟节点的讲解，了解我们柜台系统的延迟精细化管理。 （上期所实盘延迟数据） （大商所实盘延迟数据） 上面2张图是在某期货公司实盘中截取的客户交易延迟情况，由于目前大商所和上期所比较活跃，暂时先拿这两个市场做一些讲解。其中我们需要重点关注几个数据： Delay： 指交易订单从柜台收到交易所返回回报信息发送给client端的整体延迟，也叫TotalDelay。 Exchange： 指订单从柜台系统连接交易所API发出去（包含交易所网络）到回报信息返回柜台接口API（包含网络），交易所端的整体耗时。 InnerLoop： 指订单从client端API收到穿过柜台系统从交易所API发出+回报从交易所API收到穿过柜台系统从client端API发出的整体耗时。 Up： 指订单从client端API收到穿过柜台系统从交易所API发出的耗时。 Down： 指回报从交易所API收到穿过柜台系统从client端API发出的耗时。 上图可以看出不管大连还是上海，柜台的内部平均延迟均在15微秒以内。这里可能有些人会有疑问，为什么上期所的延迟数据有的高达15毫秒，最低的仅有不到400微秒呢？ 上期所网络延迟（上期大厦到上期所前置）实际是TCP连接仅有300个微秒，由于上期所的合约有的非常活跃，交易量大；有的是非主力合约，不活跃交易量小；再者，有的订单所报的价位大家都在抢；有的订单仅仅是为了测试订单速度（如卖开涨停板价格或者撤单），因此交易所撮合核心在处理不同类型订单的时候根据其繁忙程度产生了不同的延迟差异，即活跃的合约或者抢手的价位自然报单量大、撮合时间长、排队时间长；非活跃合约或者类似于长跌停板这样的价位订单，报单量小、撮合时间短、排队时间少。 为了精确计算柜台各个节点所产生的延迟信息，如下图设置了多个时间戳来观察柜台内部各延迟。  柜台延迟计算 我们在交易所API连接处设置了上行和下行时间戳、在client端API上下行设置了时间戳、在交易核心的订单处理上下行设置了时间戳，来观察系统内部数据包（即订单或回报）分别的收发情况。针对每个节点统计，定向的优化内部各个节点延迟。 通过对线上系统的观察，不断针对系统内部进行精细化管理延迟节点，使我们系统达到了实盘10微秒以内的延迟速度。 交易延迟怎么办？？？ 点击下方空白处查看答案 当然是选择量投QDP啦！！！ 量投科技 ”  |
|
|
