现在VN Station升级到2.1.8.1，而github版本并没有同步更新，请问这样做是有什么原因吗？
用Python的交易员 wrote:
跟国君期货联系了下，目前的情况：
- 国君是行业第一家升级的
- 和6.3.15向下兼容
因此vn.py这边为了其他期货公司的兼容性，暂时不升级了。
最关键的还是6.3.19向下兼容6.3.15吧。
这不是很明显的权限问题吗？
rqdatac.share.errors.PermissionDenied: Not permit to get minbar price：
没有权限获取分钟bar数据。
其实更关键的是。。。交易合约作为参数可以调整。省的每次删掉重设。
更新一个bug修复：
bug表现：
大多数时候大家都有simnow第一套环境测试，该环境没有期权。
当在有期权环境的实盘订阅指数合约时，将会连同除所有该品种期货合约之外的期权一起订阅。
这将会导致，额外订阅了N多合约后使得Tick事件大大增加，对系统造成了很多额外的不必要开销。
解决办法：
修改vnpy\trader\engine.py中OmsEngine中的get_all_index_trade_contract，
在
for vt_symbol, contract_data in contracts.items():之后添加过滤：
if contract_data.product != Product.FUTURES:
continue记得在文件头部引入Product：
from .constant import Product1、没有理想结果这事继续努力就好。
2、清空数据之后多次检查一下。
3、rb888截图错误。
这么好的问题没有人回复呀
hxxjava wrote:
kingmo888 wrote:
hxxjava wrote:
kingmo888 wrote:
直接基于portfolio_manager改造吧，这个是多品种的，构造了指数后从这里多品种来做。
谢谢，一直没有关注portfolio_strategy，原来是这样的，不错！
后来经过分析，感觉还是不如cta引擎来的方便。因为要维护理论持仓的时候，真的挺麻烦的。
用米筐的某个主力合约前复权的xx888来跟踪主力合约的做法确实比较合理些，只是xx888无法订阅，在实时行情下需要对指标合约进行合成处理！。
咱们已经有非常优秀的指数实时合成方案啦，即插即用的。目前我已使用。
适合所有gateway类型的指数合成方案
https://www.vnpy.com/forum/topic/5242-gua-he-suo-you-gatewaylei-xing-de-zhi-shu-he-cheng-fang-an
月总的教程不如楼主的细致。楼主的基本是即插即用。哈哈
远山 wrote:
看了楼主几个帖子，感觉为vnpy做了很多非常有价值的缺憾补全，同时也难以想象，一个发展多年的框架居然连这些最基础的东西都还需要用户来做补充。想当年写个简单的通信库，这些都是首要考虑的功能。
很多时候跟你有相同的感触。
Bambi wrote:
请问有办法优化吗，我现在发现存到mysql会有大概20分钟多的延迟。全行情的数据太多了
https://www.vnpy.com/forum/topic/5238-you-mei-you-yi-chong-kao-pu-de-lu-zhi-quan-shi-chang-xing-qing-de-fang-fa-ni
昨晚发感慨竟然打了这么多字，夜深人静的时候是真不能多说话。
更新一下目前的暂时的解决方案：
数据库：postgres
数据库操作文件中postgres的on_conflict操作改为on_conflict_ignore操作。（此处需要感谢上弦之月）
dr模块上，tick的逐个存储改为累计+定频存储。具体来说就是构造一个tick列表，当列表累积到一定量（如1000个tick）时数据库操作批量存储，或距离上次存储的时间超过N秒后存储。
当前市场流动性下，全市场期货合约的tick大约2秒1000条，通过上述操作可以使数据库操作频率下降上千倍，数据库的插入速度就上来了。
大半夜的有挺多感慨
从需求层面来说，
1、10年+的TB/金字塔等三方软件的使用习惯；
这些商业化软件连接对方行情服务器后其实本地也是有缓存了数据的。多账户交易也很顺畅。
2、多品种交易的需求。
意味着订阅只订阅部分合约的方案是个伪命题，现在都是多品种交易，而品种或许只要流动性好的品种都有可能去交易。流动性差的品种就算是做了订阅，因为其本身数据极少，不会对引擎产生什么压力。压力核心还是来源于流动性相对好的品种（比如市场前2/3）。
如果基于指数交易，那么意味着必然需要有个数据累计的过程，不然要算信号的时候没有历史数据就尴尬了。
3、分布式交易的不足。
当然，期货市场中程序化参与主体中，从人数上看可能个人交易者是大多数，看起来是个需求，但这部分人里面大多数人甚至没有能力使用vnpy，只能使用第三方商业软件（就像A股市场里散户新开户数量又在创新高，但从资金规模的划分来看，散户的户数新高，但资金占市场比例是在下降的。）。
虽然有RPC的服务端-客户端模式可以分布式交易，但是多账户+多服务端客户端对低成本下的运维管理其实造成了不小的压力。
vnpy作为一个发展多年的相对成熟的产品，在功能上或者横向扩展上做到了无出其右，但是也只能说这个功能我有，但每个功能的压力测试做没做到，做没做好呢，我觉得这块还是有相当大的进步空间。
就像全球做的比较大的开源软件（不限行业、不限功能）来说，它们必然能够做到支撑起一个高度商业化需求来获得收入维持运营（如果非要强调很多单靠基金会活着，当我没说）。
定位其实挺关键的——到底是做个万金油，还是做到领域专精然后再扩展其实是挺纠结的。我算是陈总一推出vnpy就了解学习的第一批人了，那时候vnpy是起于期货CTP，发展到现在有那么多接口那么多市场可以交易。但是CTP方面真的高度完善了吗？乍一看回测、交易、仿真、数据落地好像都有，真的很完善。但真是这样吗？好像又不是，比如说，CTP接口的退出就一直是没有做好，真的是做不到吗？好像不是做不到，是关注点并不在这里。视野高了，细微处可能容易被忽略。
翻了下聊天记录（别问我为什么换了这么多次电脑还有，我也很好奇和惊喜），跟陈总的聊天竟然还有。
那时候从15年跟着学C++的编译封装，到后来弃坑，到现2.1.7在再入坑，兜兜转转好多年过去了。很有幸，我还活在这个市场之中。而彼时关注的一些细节问题至今仍然存在。限于个人能力吧，五年多的时间至今未从vnpy上以程序化的方式往实盘账户下过一手合约，不得不说是很遗憾的事情。
斗转星移，时过境迁，我又回到了当初弃坑的问题上，
而这次，我不会再放弃。
RT，
订阅全市场所有合约的Tick，无论用什么数据库存储，都会因为存储造成事件拥挤，结果就是当前时刻处理的数据可能还是几分钟甚至几十分钟前的行情。
请问，目前用vnpy的话，有没有可能做到期货全市场合约无延迟（低延迟）录制？
谢谢。
shunyuzhiqian wrote:
BELLCOUSIN wrote:
应该就是
在vnpy/gateway/ctp/ 增加以上文件: ctp_gateway_double.py
在vnpy/gateway/ctp/init.py 导入包from .ctp_gateway_double import CtpGatewayDouble在run.py里面:
from vnpy.gateway.ctp import CtpGateway from vnpy.gateway.ctp import CtpGatewayDoublemain_engine.add_gateway(CtpGateway) main_engine.add_gateway(CtpGatewayDouble)在ctp_setting配置文件里面. 配置下ctp_setting增加下
"次行情服务器": "***.***.***.***:****",为啥我会重复推tick...
不是用hash过滤了吗
请大佬解答下我哪里步骤错了.我觉得有可能是self.tick_buffer的问题
两个行情源同时连接，打印的时间戳各自是各自的，他肯定是会有重复tick的呀。
最小3个字符在有时候会不太合适，
举个例子，之前在排查融航中文路径崩溃问题时候，想搜一下融航相关，关键词就是融航，但是不让搜，只能【融航 空格 扩展词】，社区的帖子不是那么多，可能方向就搜偏了。
建议供参考。谢谢。
charlesttt wrote:
用Python的交易员 wrote:
下单的时候，价格必须是pricetick的整数倍，否则就会被拒单
请问老师，在CTA 回测里，如果输入不同的价格跳动 数值 作为参数，会产生不同的回测结果。这个原理是什么呢？谢谢
这就是策略层面的逻辑了。
以RU为例，最小波动价位是5，你如果设置的是10，其实意味着你每次交易多支付了5个点。这其实可以理解为在正常最小跳动价位基础上，你人工设置了1跳的滑点。
