开云体育

While your post is quite short, you include a lot of interconnected details that probably cause the "fuzziness" and unspecific answers by API support. So let's try and "divide and conquer".

What kind of data does your strategy really need?

I guess your first step is to define exactly what data your strategy really needs. If it needs size information for every individual trade that happens, only the TickByTick feeds can give you that information. But if cumulative volume over a certain time period is sufficient, candles/bars may work, too. But keep in mind that the only real-time bar feed currently available is the 5-second reqRealTimeBars() and there is no 1 second real-time feed. But you could easily make one from a TickByTick feed yourselves.

Since you specifically mention? 'large "tick" trades', I am going to assume that none of the bar feeds will work for you and that you need to use TickByTick feeds.

Keep in mind, though, that you see only the TRADES (level 1) not the ORDERS (level 3). A single order for, say, 10,000 units, will probably be filled from many smaller trades and likely at several different prices. You will see those individual trades but never one with "size == 10,000". Having said that, you can detect from reqTickByTickData(TRADES) feeds when something out of the ordinary goes on.

?

Back-test with the same data that your live trades gets

Assume that the various data feeds provide different values so you must make sure that you back test with the same (equivalent) data that your live trader would experience. I suggest you make a small client that records next week's reqTickByTickData(TRADES), download the reqHistoricalTicks() next weekend, and compare the results.

For many instruments, reqHistoricalTicks() will provide additional data that is not be part of the real-time reqTickByTickData(TRADES) feed for the same period. Those are generally "non-reportable" trades and can be filtered out by looking at the specialConditions field of the HistoricalTickLast objects. You should be able to convert downloaded reqHistoricalTicks() into feeds that are almost identical to what reqTickByTickData(TRADES) would have provided.

?

Make your trading logic truly TickByTick

Set your trading logic up such that it is not aware of where the data actually comes from.

During a live session you will receive one tick at a time (though possibly hundreds or even thousands of ticks during busy seconds) so that your trading logic would provide an event handler interface such as "onNextTick( TickByTickLast last )" that consumes each individual tick when it arrives. You would wire that event handler up to a reqTickByTickData(TRADES) feed in a live session or, during back testing, feed it one tick at a time from a previously recorded reqTickByTickData(TRADES) file or from a (filtered) reqHistoricalTicks() download.

And when you back-test, you obviously want that to run as quickly as possible and many times faster than real-time. So the "chunked" download behavior of reqHistoricalTicks() does not really matter. BTW, last time I checked IBKR allowed you to request up to 1,000 ticks for each call to reqHistoricalTicks(), though you would always receive data for full seconds so that you occasionally receive more than 1,000 ticks.

?

Time stamps in TickByTick data

Most of IBKR's time stamps still have a resolution of 1 second and that includes TickByTick data (live and historical). But that is generally no issue since the logic consumes one tick at a time anyway. During live feeds you can time stamp the arrival time with a higher resolution time stamp (I use the Java Instant with a precision of 1 nanosecond, but a realistic resolution on my server of 1 microsecond) and get a rough feel for the spacing between trades within the second. For recorded feeds or historical download you just need to make sure that you save the ticks in the order your receive them.

?

I guess I could write an entire book on this topic, but I hope these thoughts help.

闯ü谤驳别苍

?