想研发高频交易模型，请教下用什么软件好？

关于vba的问题，我的浅薄的经验可以总结一下，vba效率确实是不高的。解释型语言，这个就别争了。但是对于k兄说的vba每秒下单几千笔其实也很正常，看怎么写。如果是设计一个缓冲区，由循环直接写入一些订单的参数，别说几千笔，几万笔也是能在一秒内完成的。其实，这东西下单不是速度瓶颈，瓶颈在于网络速度和做决策时候的那些算法，如果是一些非常简单的策略，没问题，如果是极其复杂的，那么就需要考虑计算速度了。甚至包括实时的数据挖掘（我怀疑席梦思的策略里有一部分这个东西），拿vba做个bp训练一次看看，估计绝大多数人都会骂娘了。在需要复杂算法时就需要考虑使用何种语言了。另外，其实vba的问题不只是速度，包括稳定性，对机器的压力其实都有问题。关键是适合。其实我建议以后大家讨论这些东西的时候就直接上一些代码，不一定是成功的，一些失败的代码更好，直接上代码一是避免比较口径不统一，比如都说c++快，但是要是在一个循环中要求不停的显示循环结果和在vba之中在循环过程之后显示结果一定是vba快，因为机器显示结果是非常耗时的，还比入连接数据库等等，方式不一样，速度肯定不一样，加锁不加锁也不一样，为了有可比性，最好直接上代码。其次，说实话，互相直接说这个那个多没意思，这个说干过，那个说你没做过，直接上代码，很直观，也避免了互相的怀疑可信度，咱们大多数都属于孤狼，单打独斗的，要是连个代码都摆不平，大家也真都不好说什么了，是吧？或者，最好就是回到原来的那种氛围中去，安安静静的讨论问题。

 

http://www.lmax.com/popup-how-we-measure-mtf-latency?width=640&height=500&iframe=true
http://www.lmax.com/popup-how-we-measure-trade-latency?width=900&height=600&iframe=true
讨论任何问题之前先界定问题。不同的人对于同一单词理解相差很大。

同意ku“订单速度的最大瓶颈不是语言，是网卡。” 之前有个搞IT的前辈也这么说。

自己之前的测试想法：
（单个订单测试）：
第一个OnTick 事件来时，随便给一个不可能成交的订单，然后第一个OnRtnOrder事件来的时候，重复之前的订单，不停的“攻击”。统计从OrderInsert到 OnRtnOrder的延迟
（一篮子同时报单测试：）
随机100只股票同时报出，等待所有100个OnRtnOrder事件都回来，然后再次发起“攻击”，统计所有OrderInsert完毕到 OnRtnOrder的延迟


目前没做一揽子股票测试。
单个订单测试结果：

小弟12年测试结果：
托管服务器：张江机房
网络连接：内网
ping 172.18前置机延迟时间分布均值 0.8ms（数据包一个来回）
traceroute 中间经过4道网关。
服务器：DELL （具体型号忘了8核 2g mem 160G SAS）
OS：centos 5.7 文件系统： ext3 网卡：gigabyte 1000M
编译器和库： GCC 4.4 boost 1.49（filesystem库）
整体架构：(mdreader + trader ) as 2-producers --> locked message queue with mutex + pthread_cond_wait -> 1-consumer strategy container vector ( containing multiple stratigies )
策略部分架构：经典的有限状态机模式。

单个订单测试结果：直接看快期上面一堆错误订单返回的时间，悲催的发现一秒钟 21~23 订单，然后问了上期，CTP发出去是要经过风控平台的。所以现在老老实实的看书，在互联网上做交易，没条件做高频。

 

你怎么会那么慢，我在自己家里下单RTT也只有10ms，ping大概有5ms，就是说CTP那边整个过程用了大概5ms

 

额，晚上回去看看之前笔记，再拿夜盘的测一下。那个数据可能记成模拟服务器的结果了。反正当时感觉很慢。

 

这下对了，跟你的差不多了。。查之前日志发现慢是因为同一线程内带了调试的输出。

sizeof(InputOrderField)=184,sizeof(Orderfield)=576,sizeof(TradeField)=320

来自 125.64.21.51 的回复: 字节=576 时间=40ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=44ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=40ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=47ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=74ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=38ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=39ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=46ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=41ms TTL=246
来自 125.64.21.51 的回复: 字节=576 时间=44ms TTL=246

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:43:44,,譵
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:48,,譹
,a1403,买　,开仓,已撤单,-1,-,1,0,已撤单报单被拒绝价格跌破跌停板,18:41:47,,譹

 

由上面的讨论，其实大家会发现，交易成功对于专业交易员的难点其实还是在于策略模型化，或者说策略程序化。硬件或者网络的速度细节，专业交易员无法解决。除非我们做生意，搞成数十亿美金规模的基金。
我个人关注的策略细节，其实大多不是在策略本身，更不是在网速。策略的implementation，对我来说，意味着很多人都不会考虑的细节。
今天闲着没事，就针对A股展开谈谈。在策略的模型化过程中，有以下几个容易被忽略的问题。
1，数据精确度问题。以我目前的了解，A股数据5分钟级别的数据基本上不可靠，不论是哪个来源。（不同意的请拍砖！欢迎拍砖！）这其实也说明A股市场高频交易基本上是无法实践的理论区域。日线数据也有精确度问题，但差距不大。我现在正在研究30分钟和60分钟级别的数据，希望能够使用。如果大家对这个数据精度的重视度不够，估计交易系统会出大问题。
2，量化平台问题。这其实也是个超大的问题。同一个策略，在不同量化平台上对同一数据进行回测，得到相同或者相似结果的平台，少之又少。大家不妨试试。甚至同一软件，不同版本（比如wld现有版本和过去的几个版本），测试结果也常常不同，甚至普遍完全不同。这个问题是几乎所有量化平台都有的问题。目前，我个人只是选用商业化时间较长的通用量化平台，但也无法保证准确度。如果有人对此曾有过研究，愿意深入讨论，我愿意洗耳恭听。我个人觉得这是受限于目前编程技术方便而且灵活导致了许多程序模块潜在的不同。这是量化交易中最有爆炸性、最不确定的因素。所以许多投资团队，都是用自己开发的量化平台。我个人甚至参与过这种思路的团队，但对此也有疑问，怎么能保证自己开发的程序的bug就比商业软件少呢？更何况商业软件有众多的用户使用，原则上更容易发现和纠正错误。
3，回测结果和实际交易的差别。在忽略第二点的前提下，如果你经常比较交易记录和交易系统回测结果的话，这两者之间的差别常常非常明显。甚至我个人碰到过多次量化交易平台miss掉交易信号的问题。因为我的交易instrument比较多，在账户里就没有检查，甚至有时完全无法检查。在我的交易生涯里，至少每年有1-2次没有交易信号出场只好手工清仓的情况。
刚好有点急事，不能说了，改天再补充好了。期待大家讨论

 

补充一下上面第三点。这样的情况，有可能是真实价格数据和记录下来的行情数据有差别，也可能是交易系统本身的问题，也可能是量化交易平台的问题，也可能是slippage或者佣金的问题。
请教大家，对上面三个问题，你们各自采用的解决方案是什么？

 

我在做美股，所以
1、基于每笔的，不存在数据精度问题，一笔就是一笔，完全是即时数据，不管什么接口，只要是标明提供tas的，数据就是一致的。就算不一致，其实也差不了太多，在统计结果上也是一致的。
2、直接是使用。net，不存在这个问题。
3、直接调用接口，不会会被miss掉，无论如何都会有返回值，就是服务器端不接受订单，一定会返回错误号，有专门的程序对订单错误跟踪。

 

1，精确度问题：根源在于我们用的都是二手数据。没条件用一手数据。

如果是期货：国内一级行情转发商用的数据源都是一样的500ms，所以一手数据应该没问题，问题在于不同的平台从K线开始就不一样了，之前比较过文华，博易大师，金字塔，开拓者，万点生成的日线以内的bar会有3种以上不同的时间序列。
按照自己从ctp托管服务器收集逐个tick比较过，文华，博弈大师K线生成方式不同，现在记得比较清楚的是博弈大师从01.000秒开始，然后下午是从01.500秒开始生成新K线。文华从00.000开始生成K线。这样在 数据压缩成K线的 阶段 就开始不同，后面所有指标完全不一样。

如果是股票：比如同花顺，大智慧，然后其他的数据源数畅，网际风，之前参考过华荣的帖子《逐笔，分笔，逐单，分时数据概念区别》，了解到不同的软件对于逐笔数据汇总的方式不同，看到的分笔数据（而且还是快照切片数据）几乎没有一样的。比如有时经常看到挂单量多1 少1这个可能就是对于零碎股的四舍五入方式不同。

问题1，可以认为是问题2的一个方面，即量化平台中数据模块。我自己觉得，
1）如果只能局限在现有平台上搞，那按照“在哪个平台上交易，就以那个平台的数据为准”，然后其余的平台测试策略的“可扩展性，数据容错性”。
2）策略尽量不要太“精确”，比如因为一个tick的数据误差就开反向单之类的，或者因为一个tick误差影响后面所有单子的逻辑条件。

数据和策略开发是跷跷板，数据精度越高越接近一手的数据，越能够开发精度高的tick级别策略，不然只能以“数据大约在某个误差范围内”这样的前提假设下设计策略和实盘交易。

3）多个数据源的问题，还可以谷歌一下 对冲基金 如何解决 外汇交易 不同撮合平台不同数据源的问题。（不过他们的问题不在于二手数据，而是多个一手数据如何清洗整合）

问题2：除了问题1里面的平台数据压缩成K线的方式不同之外，还有不同平台的内建函数算法不同。即使是wlb，，版本5是C#，之前是类pascal，整体架构发生了很大变化，内部算法未公开。个别函数实现细节可能就不一样。
对于问题2.
1）还是倾向于自己DIY，保证通信模块尽量简单直接，您的掉信号的问题可能bug在这一层。用平台的话尽量输出详细的日志。有些黑天鹅错误再次出现的概率很小。
2）关于bug：商业软件面向的是普遍需求，平台是大众化的，很多繁杂的功能，bug自然很多，自己做交易平台，可以只开发最迫切需要的模块，即使可扩展性很差。一切设计以“保证逻辑准确无误实现”为最基本准则。
功能和bug，这也是一个跷跷板。多一个功能，多N个bug。

问题3：几乎就没有完全一样的时候。合约流动性，交易所撮合机制，如果外盘的话还有经纪商订单传送机制等，都会影响。比如 海洋上IB板块经常看到有人遇到 订单问题。
不过您的miss掉信号的例子貌似属于问题2.
问题3，只能在回测的时候做压力测试了。加高手续费，拿表现最差的时期分析等等，这要发挥想象力了。

以上只是技术上的解决办法，心理上来说，要相信数据，但不要全信数据。自己的策略逻辑越靠谱，即使垃圾数据进来这种黑天鹅事件也不会损失太多。

何不另开帖子讨论？
另外，@kuhasu CTP内核接入是指不通过API，直接用FTD协议接入？？求教啊~~~~

 

讲得好。本想另开贴，但发现回复只有你一个，所以还是就在本帖讨论算了。
1，谢谢你推荐华容的帖子，仔细看了看，是些普通的概念，不过讲的很详细，可以帮助新人。我谈的精确度问题，不是股票的高频数据，只是5分钟数据。目前付费的，或者网络上下载的，大都不同。海外股票价格，不少tick数据都比较一致。目前来看，A股的5分钟数据问题似乎无法解决。有点郁闷。
2，我关注的，主要是算法。你说的原因，我也考虑过。但是不仅仅wld，包括其他流行软件也多没有统一的测试结果。所以我个人使用的策略，一般情况下，都是非常简单的策略，而且在多个软件上测试。
不过非常感谢你对商业软件和DIY开发软件的认识，对我有些启迪。DIY软件针对自己的需要，所以会比较简单，出错的概率会减少。确实有道理，看来还是要自己干才行。
3，问题目前似乎没有解决方案，因为出现问题的原因太多。有策略原因，有回测原因，有软件问题，有执行问题，有数据差异，有......估计需要把问题原因分类后逐一解决。得仔细想想......

 

EXCEL的最高输入是65534行，不能够超过这个数。

 

国内目前没有高频交易机会，开发了没太大用。豆粕可能能达到你的高频要求，但是你beat不过手续费

 

你OUT啦，EXCEL现在能输入100万行了！

 

乃们用滴不似一个版本，哈哈

 

汗，咱们就别在excel上再讨论了。第一个，要看高频算法的复杂程度，如果运算很复杂，那么excel估计是没戏。比如，我曾经想做近6000万次的bp神经网络模拟，别说excel，没有超算服务器连门都没有。可是如果很简单的策略，比如规定一个数字，超过就买，否则就卖，这个excel绝对胜任。再有就是怎么用，即便是超级复杂的策略，也可以用c写好dll，将运算等耗时的工作完全交给dll或者其他的exe去做，数据存储交给数据库，excel就是个显示，这也算excel开发，我记得很久之前有人弄的进销存号称是excel做的，后来一看完全是excel的界面，中间层什么的全打包成dll，后台是sqlserver，我觉得如果是这样，搞excel也无不可。