堡垒。执法问题 - 页 87

新评论
 
prostotrader:

现在有道理了!

在异步情况下，只写一行

2017.02.17 16:20:47.300 Trades  '1007932': sell limit 1.00 RTS-3.17 at 121520 placed for execution in 8.287 ms

与此相对应。

2017.02.17 16:20:47.300 Test_delay (RTS-3.17,M1)        8.305

而且，在日志中没有其他的线!为了配合这个。

2017.02.17 16:20:47.307 Test_delay (RTS-3.17,M1)        15.644

在异步处理的情况下，日志显然是不完整的。

但在同步处理中，日志中有两行内容

2017.02.17 16:20:47.316 Trades  '1007932': sell limit 1.00 RTS-3.17 at 121520 placed for execution
2017.02.17 16:20:47.323 Trades  '1007932': order #54042531 sell limit 1.00 / 1.00 RTS-3.17 at 121520 done in 15.978 ms
而且它们与记录完全对应
2017.02.17 16:20:47.323 Test_delay (RTS-3.17,M1)        16.033

这就是为什么同步和异步模式的执行时间相等（这在逻辑上是应该的），而终端日志报告说异步模式的速度是两倍。这是个谎言/错误!

我们可以得出结论。

在异步模式下，日志并不完整，会产生误导。

 
fxsaber:


可以得出这样的结论。

在异步模式下，日志并不完整，会产生误导。

是的，但不幸的是，这并没有解决延迟问题....。
 
prostotrader:
是的，但不幸的是，这并没有解决延迟的问题....。
  1. 目前还不能参考异步模式日志--你必须自己测量。如果你给SD写信，这是很好的事情。
  2. 刹车问题在SD中已经解决了好几天了。快速播放的脚本已在公共领域发布。显然，开发人员会达到这样一种情况，即脚本首先在他们的测试平台上不会显示任何滞后（那是快），然后在用户终端上（那是慢）。因此，一切都相当乐观。
 
fxsaber:
  1. 目前还不能参考异步模式日志--你必须自己测量。如果你给SD写信，这是很好的事情。
  2. 刹车问题在SD中已经解决了好几天了。快速播放的脚本已在公共领域发布。很明显，开发人员会达到这样一种情况：脚本首先在他们的测试台上不会显示任何滞后（那是快的），然后在用户终端上（那是慢的）。因此，一切都相当乐观。

在SD写了一个很长的时间。

我也很乐观 :)

 
prostotrader:

很久以前我就给SR写信

我的申请得到了非常迅速的回应。也许我使用的语言比你的语言更容易被开发者理解。

我有时发现很难理解你的意思。

 
同事们，请就这一点提出建议。我一直在FORTS上使用ORDER_FILLING_RETURN 策略，这里我有一个任务是测试ORDER_FILLING_FOK。

但有时FOK不工作，写出错误4756。
我正在使用SB，特别是用于购买。
bool  CTrade::BuyLimit(
                         1.0,                       // объем позиции
                         текущий аск,               // цена исполнения
                         NULL,                      // символ
                         0.0,                       // цена Stop Loss
                         0.0,                       // цена Take Profit
                         ORDER_TIME_DAY,            // тип истечения
                         0,                         // время истечения
                         ""                         // комментарий
   )
谢谢你的提示。
 
Dennis Kirichenko:
同事们，请就这一点提出建议。我一直在FORTS上使用ORDER_FILLING_RETURN 政策，现在我的任务是测试ORDER_FILLING_FOK。

但有时FOK不工作，写出错误4756。
我正在使用SB，特别是用于购买。
bool  CTrade::BuyLimit(
                         1.0,                       // объем позиции
                         текущий аск,               // цена исполнения
                         NULL,                      // символ
                         0.0,                       // цена Stop Loss
                         0.0,                       // цена Take Profit
                         ORDER_TIME_DAY,            // тип истечения
                         0,                         // время истечения
                         ""                         // комментарий
   )
谢谢你的提示。

4756

发送交易请求失败


与填写订单无关。

追踪SB，也许你会看到错误发生的地方。

 
prostotrader:

4756

发送交易请求失败


与填写订单无关。

Traceroute SB，看看你是否能看到错误发生的地方。

以下是订单 和交易记录 的摘录。
2017.02.22 10:00:00 52884143 MIX-3.17 buy limit 1.00 / 0.00 213 700 213 525 213 900 2017.02.22 10:00:02 rejected Неполное сведение FOK заявки.


 
Dennis Kirichenko:
以下是订单 和交易记录 的摘录。
2017.02.22 10:00:00 52884143 MIX-3.17 buy limit 1.00 / 0.00 213 700 213 525 213 900 2017.02.22 10:00:02 rejected Неполное сведение FOK заявки.


检查经纪人是否支持FOK浇注

//---Filing mode
  int filling_mode = int(SymbolInfoInteger(a_symbol, SYMBOL_FILLING_MODE));
  
  if((SYMBOL_FILLING_IOC & filling_mode) != SYMBOL_FILLING_IOC)
  {
    MessageBox("Символ " + a_symbol + " не поддерживает filling IOC режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
    return(false);
  }
  
  if((SYMBOL_FILLING_FOK & filling_mode) != SYMBOL_FILLING_FOK)
  {
    MessageBox("Символ " + a_symbol + " не поддерживает filling FOK режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
    return(false);
  }

添加

再看SB函数 bool CTrade::FillingCheck(const string symbol)

 
Dennis Kirichenko:
以下是订单 和交易记录 的摘录。
2017.02.22 10:00:00 52884143 MIX-3.17 buy limit 1.00 / 0.00 213 700 213 525 213 900 2017.02.22 10:00:02 rejected Неполное сведение FOK заявки.


限制器可以是FOK吗？

在论坛上，他们发布了一个自动填充类型选择功能。

1...808182838485868788899091929394...156
新评论