Yes, but the default is that fast strategies request data faster than slow strategies. You can set this up with TickTime. For streaming data the plugin must trigger a callback function.

According to the manual, TickTime is for triggering tick() function.
Does it also influence frequency of data snapshot requests to the broker api?


Does it mean that in the current IB plugin it is not defined?
Is this then to be used in reqMktData() call?

The context for my questions is not that I want to execute an HFT strategy. It is rather to make sure that O-H-L-C are as correct (reflect full market activity and equal to historical bars) as possible.

Jcl,
please reply..
I am also not clear on why
How does a user-defined callback function relate to the Broker plugin subscribing (or not) to the streaming data updates?

The answer on both questions is yes - TickTime affects the price request frequency, and the current IB plugin uses no streams. If I remember right, streams cannot be used with portfolio strategies.

The mentioned callback function is BrokerProgress, to be called on incoming ticks. If the function is not called, the request frequency is determined by TickTime.

THANKS!

Dear JCL,

I have provided to support all the logs/evidence that IB plug-in requires a rework. They accepted it, but the timing is "next time" - which does not help things a bit.

In addition, the requested increase in the number of ticks Zorro stores/plugin requests came implemented as a read-only field to "GET" (what's the use of this??) - as confirmed by Support, - contrary to what's written in the manual and intention And IB Plugin does not seem to support it anyway.

Would it be possible to rework the IB plug-in sooner rather than later?
It is barely usable in production in its current form + IB API has undergone quite some changes over the last year.

Thank you very much in advance.

I do not really understand the objection against GET_MAXTICKS, but can confirm that the IB rework is planned for quite soon and will include several changes. For instance switching the price source from ask/bid to trades.

The objection against GET_MAXTICKS is that it is a READ-ONLY field, and so does not allow the end user to experiment with changing this value.
And the plug-in developer knows about this value anyway and would not access it via BrokerCommand(). What would be the use case for this command for the end-user?
Please let's make it also "settable".

Great news for the IB plug-in! I have 2 suggestions:
- for FX/metals let's report *mid-point*- as provided by IB - as Trades. There are no Trades per se for these assets.
- let's also implement IB's *5-sec True RT bars*.
Such 5-sec bar encompasses ALL ticks and comes with a 250-300ms delay - which is good enough for anybody trading at 10-15min+ resolution.
These bars come already cleaned from IB's Historical servers; are exactly equal to the "Historical bars" one can download from IB - and so can be saved to *.t6 structs already in RT (either as 5-sec or as 1min).
250-300ms delay - and you can trade exactly what you would have tested on!

For this to work properly in all cases, Zorro should ideally allow sending a real stop order to the broker (like it already allows with limit orders), not just simulate it.

GET_MAXTICKS is not for the end user, but instructs Zorro to download data in the returned packet size. The plugin developer, not the end user, is supposed to experiment with this value.

The price source switch command could also be used for switching to RT bars. It they are not a big hassle to implement, we can include them.

Zorro can send real stops to the broker, but the IB plugin does not support them. AFAIK the IB API has no stop order, but requires two orders instead.

So, can a plugin developer SET this value to experiment? Or you set it?
Let's set it to 2500-3000 for IB by default - as per IB's recommendation!

They should not be. Would be really great to save them to *.t6 structs in RT.

IB API offers a huge variety of orders. Depending on the exchange, some are native and some are simulated. https://interactivebrokers.github.io/tws-api/basic_orders.html#stop

Stops are mostly simulated, but they would definitely be effected much faster by IB, then by Zorro. So, please implement BrokerStop() for IB.

- Limit orders are native for most exchanges; but what Zorro actually implements instead is a "30-sec Stop-limit" order (via ORDERLIMIT flag+SET_LIMIT BrokerCommand).
Please add a BrokerLimit() command to allow placing resting limit orders (or a similar functionality to do that).

Overall, most limitations on orders mentioned in the manual re NFA are handled by IB internally; So, a Stop or TakeProfit can safely be sent as Stop and Limit order by the plug-in; without asking the user to separately call a BrokerStop() or BrokerLimit()/ ORDERLIMIT. It is less efficient/costlier to handle them on Zorro's side.

Some other wishes:

- OrderIDs - please return OrderId, instead of TradeIDs (=0 because they are not supplied by IB)

- please return Api Errors and Order State/ Rejection reasons

- please extend or allow to extend order(int type):
IB has a lot of great order algos, and there should be a way to use them from within Zorro. "Trails" and OCA, Combos have native IB implementations.

- please allow to receive IV/Greeks from IB

Thank you!