主题：实盘成交的时序问题

1.请提供你dll以及整个测试策略。

 

《1》根据你表述的的现象，要你是在信号检测时，你的策略还未运行解决，造成依旧检测到倒数第二次的信号。这种情况，你可以试一下，将周期放大看下是否还有这类现象。

上面的现象，需要你提供你debugfile输出结果时，其图表上信号所在k线位置。即，如果你策略运行一次的时间大于k线自身周期的时间，如果是这种情况，那就没办法了。这种属于效率类问题， 你只能考虑优化自己的策略，或者彻底脱离图表完全使用c++方式看下是否可以满足。

如果不是，可以考虑试一下下面方式，

《2》还有一种解决方法，使用固定时间间隔， 将策略改成使用固定时间间隔模式，条件判断改成使用上根k线信号作为当前k平仓信号的判断依据。

1. 已经和你们的客服说过很多次了，策略是肯定不能提供的。
2. 我们在小时线上测试过，问题还是存在的。
3. 用固定时间间隔，问题同样存在。
我觉得是时序问题，你们为什么不把问题提交给开发人员，让他们判断一下呢。

策略自身的执行和信号检测时分开的。并不是串联关系。

如果说你策略在执行过程中，策略还在最后一次运行中，那么为检测到信号漏单，是存在这种可能的。

 

 

另外，如果你不能提供策略及dll，开发也无法定位问题。你可以尝试使用11楼的方案2.

 用固定时间间隔的方式不能解决问题的，早就尝试过。

既然你说有可能有漏单的问题，那就说明程序有bug，难道你们的开发团队无法确定这种可能是否真的可能发生？

这个不是bug，这个只能说明策略执行效率能力超出pel本身结构所能承载的性能。

你只能考虑尝试更换能满足你计算需求的方式，如完全使用c++方式

 如果说每次都无法实盘成交，那我承认是执行效率有问题。可很多时候是可以成交的，这如何解释。
还有，你到底看了我贴上来的日志呢，我策略运行完成只比实盘交易检查慢了几百毫秒，难道这样一点时间，你们也是不允许的吗

已经说了，这个检测动作和策略执行是独立分开的，两者分别独立触发。

如果按你说的真的是几百毫秒的误差，那么按这种方式肯定没问题

使用固定时间间隔， 将策略改成使用固定时间间隔模式，条件判断改成使用上根k线信号作为当前k平仓信号的判断依据。

 

 

而你在之前你说这个方式也解决不了，那就只能说明你策略执行中信号的出现落点，肯定不在最后两根k线的位置。

策略执行过程中，所说的时间执行到输出语句时，记录的是计算机本地的时间，其信号所对应的k线位置，可能已经是倒数第三根甚至更远。也不能完全根据你所提供的时间差去处理判定。

走完k线模式。检测时机必须是k线走完下根k线生成，而此时的公式执行并不能完全同步。要不就不是走完K线模式了。一个模式触发的时机只有一个标准。

设计时就是如此。不满足你需求，你只能自己考虑使用c++独立实现了

 是设计的bug，还是不承认。我没有说有2个标准。下一根K线生成的时候检查触发是标准，没有问题。但是检查之前可以询问一下另外一个线程，它在最新k线tick生成时进行的策略运算是否完成，如果没有完成，等待它完成，这根本不是一个难的动作。windows上同步机制多了去了。