MTF wrote:
jingsiaosing wrote:
rqdata 盘中的bar不太准的，不建议使用
方便具体说说是怎么个情况嘛？
之前有遇到过漏tick的情况，rq的盘后数据也是在18:00之后才确定生产完毕的，你可以对比下盘中拉的数据(或者16:00左右的)和18:00之后的盘后数据，偶尔可能是会有对不上的
rqdata 盘中的bar不太准的，不建议使用
1M带宽足够了，这个带宽是从云服务器download数据的速度，云服务器本身的带宽大概是50M左右的
不要用print，io非常耗时的，你可以用%timeit 简单测试一下，单次print(info)大概是几十微秒的数量级，1000个合约大概就是几十毫秒，这些tick大概前后也没差几毫秒到达本机的，同一个交易所的好像还是同时到达的，你这样肯定处理不过来。engine底层用一个queue去接收tick是可以避免丢tick的。另外 OnRtnDepthMarketData里建议不要放这么多逻辑，两个datetime类相减大概也是10微秒数量级的，最好是用官方原来的方案，在另外一个线程里面处理。
vnpy的bartime默认是向前归结的，所以最后一个bar的时间戳是14:59:00,如果想修改为向后归结，最后一个bar时间戳改为15:00,可以修改vnpy/trader/utility.py 里的BarGenerator.update_tick
你看下郑商所的其他合约，应该都有这个问题。郑商所的最后一个tick的时间戳是14:59:59, 不像其他交易所有15:00:00及以后的tick，所以导致14:59:00的这个bar没有合成出来。
1.行情建议直接用期货公司给的实盘前置，不用输入用户名密码可以直接使用的，比simnow稳定
2.不太可能是带宽不够，不过无法排除网络不稳定的原因。建议直接贴出你的代码
已经实盘用了很久，没有发现你所说的丢tick情况
这是因为早盘的时候会重复推夜盘的行情，可能是ctp自己的bug，最后一个tick的时间戳会发生改变，比如郑商所的品种MA，最后一个tick本来是2022-08-17 22:59:59, 早盘推送的时候会把这个时间戳错误的修改为2022-08-18 22:59:59，整整推后了一天，导致白天所有的tick都变成了无效tick。建议在底层接口处，或者策略的on_tick处做一个过滤，tick.updatetime和datetime.now()做一个比较，相差超过10分钟的tick直接过滤掉即可。
fork之后，如果对自己的代码库做了魔改，官方源码升级后可能会由于出现conflicts而无法直接在github上merge代码，下面记录下用git命令在本地合并代码的简要步骤。
前提：下载并安装git软件，生成并上传ssh公钥至github网站
不要用self.pos作为判断开仓的条件，可以设置一个open_flag,close_flag这样的标志变量，发单后把flag置为1
TradeStatusManager的定义是放在vnpy/trader/utility.py中的吗
vnpytrader wrote:
大佬，StatusEnterReason这个数据类型如何定义的，找遍全网，都没有找到对应的定义，望解答啊，感谢！
在ThostFtdcUserApiDataType.h中
/////////////////////////////////////////////////////////////////////////
///TFtdcInstStatusEnterReasonType是一个品种进入交易状态原因类型
/////////////////////////////////////////////////////////////////////////
///自动切换
#define THOST_FTDC_IER_Automatic '1'
///手动切换
#define THOST_FTDC_IER_Manual '2'
///熔断
#define THOST_FTDC_IER_Fuse '3'
typedef char TThostFtdcInstStatusEnterReasonType;洋生 wrote:
按照如上方式更替后，发现VN station直接启动不了，请问下什么原因？就是连用户名和密码界面都启动不了。
正在重装中…
应该是替换的时候有语法错误 在cmd中用 python -m vnstation 启动可以看到报错的位置
hxxjava wrote:
jingsiaosing wrote:
对于交易非常不活跃的合约 这个方法是有问题的，比如说没有集合竞价tick。如果只交易活跃合约可以不用care
问题的核心是：
主要的问题还不在这里，主要是如果不做处理，集合竞价的tick是非常有可能产生交易信号的，
导致策略提前连续竞价时段就报单了，而此时交易接口在这段时间是无法接接受报单的，导致
策略丧失开仓或者平仓的机会。如果经过我的处理，就不会出现上述的问题。
另外：对于交易非常不活跃的合约 这个方法也是没有问题的，比如说没有集合竞价tick，自然
在新的连续竞价状态到来的时候，因为不存在集合竞价tick，所有也不需要进行时间转换，所以
也是没有问题的。
哈哈可能是我没说清楚，我说的 对交易不活跃的合约这样处理会有问题 是指直接在第一个tick(非集合竞价)来的时候把bar的时间戳加一分钟，这样合成的bar肯定是错的了。你的方案是最完善的，如果基于bar的信号来交易主力合约的话，直接给bar时间戳加一分钟，这样这个bar在收到连续交易的第一个tick时就不会推送了，而是等到一分钟后再推。这只是个取巧的方案，只适合根据主力合约的bar来计算信号进行交易的策略。
对于交易非常不活跃的合约 这个方法是有问题的，比如说没有集合竞价tick。如果只交易活跃合约可以不用care
hxxjava wrote:
jingsiaosing wrote:
这样的话第一个20:59:00的tick接收到后 会初始化一个时间戳为21:00:00的bar，一分钟之后连续竞价交易过来的tick的分钟与其相同，就不会推bar，直到这一分钟走完。
这样的做法是错误的：
- 不是所有合约都是21:00:00开盘，还有的合约根本就没有夜盘，有的是上午9：00，还有其他时间开盘的；用固定时间来判断是在凑合事。
- 只有集合竞价时段收到的那一个tick才可以这么做，其它的情况不不可以这么做。
所有的期货合约的集合竞价和连续交易之间都是间隔1分钟的，没有夜盘的品种集合竞价tick是08:59:00,股指和国债是09:29:00. 只要不是盘中重启的话，合成的bar应该是正确的。盘中重启的话不论用什么方法，刚开始的第一个bar的信息都会有问题，除非是从rq这样的第三方平台拉取。
这样的话第一个20:59:00的tick接收到后 会初始化一个时间戳为21:00:00的bar，一分钟之后连续竞价交易过来的tick的分钟与其相同，就不会推bar，直到这一分钟走完。
单纯把集合竞价tick合并到后边的第一个bar，有个更简单的办法，在barGenerator的update_tick中，根据self.last_tick是否存在来初始化bar，若不存在的话，把bar的datetime直接加一分钟
if new_minute:
self.bar = BarData(
symbol=tick.symbol,
exchange=tick.exchange,
interval=Interval.MINUTE,
datetime=tick.datetime,
gateway_name=tick.gateway_name,
open_price=tick.last_price,
high_price=tick.last_price,
low_price=tick.last_price,
close_price=tick.last_price,
open_interest=tick.open_interest
)
if not self.last_tick: # first tick defers to the next minute bar
self.bar.datetime += timedelta(minutes=1)
`在策略的__init__里面初始化self.vt_symbols可以部分解决这个问题，比如从特定csv文件读取合约列表并赋值给self.vt_symbols。这样做有一个问题是，调用self.stop_strategy的时候 会把订阅过的合约保存在json文件中，下次启动的时候会来读取这个json，这样在__init__里面赋值过的self.vt_symbols和之后读取这个json得到更新的self.vt_symbols可能会出现重复，engine会同时多次推送同一个合约
xiaohe wrote:
可以根据自己需求个性化修改策略引擎
