开云体育

You saw this but did impact your code ? Otherwise said did you try to make a request anyway ?
I suspect a pattern where IB disconnect on lazy use, (a connection is expensive as a resource)
Real Account typically are less active than Paper account which allow more experiment hence more activity hiding some difference in timing and traffic, less traffic is not always a good thing.

Also HDMS are for quering Data, this should not impact your trading capabilities

开云体育

Well, a trading algorithm based on realtime tick-by-tick data can have a problem if the time series has gaps or even ceases.
While at less liquid market hours the time between two ticks can last a couple of minutes I think a lazy use shutdown here and there is not a good idea.
As I understand the API a realtime tick-by-tick request is active and continues until the subscription is canceled.
However, it would be interesting if the API allows in a timely manner to detect that the realtime tick-by-tick supply is broken so that a new request can be initiated.
All in all the last two days my data supply was flawless and I'm in good hope.

I maybe wrong,but from what I see and practice:

0- You can't compare status of farm with a 30 seconds delay as in your evaluation.
I assume that you probably stop your Real account and start paper but didn't have both running simultaneously.

1- HMDS is for Historical request, it is? doesn't seems the farm that feed ticks (this seems to be Marketdata)

2- Hence HMDS maybe disconnected when not used with no harm or very little (waking it up require ~400ms on the first call as a wake up call, then its back to normal speed for quit sometime, at least 10 min during RTH)

3- If you want, set a watch dog that make a dummy call for a 1 bar AAPL, (or also a DAX stocks as it looks like your concern its the disconnection of farm related to Europe while this maybe related to your server location more than your marketplace)
Do it once every 3 min is enough to keep it alive. But again this may only be an issue for Historical and I don't felt any need for that.
As per Europe: be careful that RTH are earlier than US and it looks to me like IB tolerance to unused connection is lower (faster disconnect) aside of Local RTH.

4- Try using TWS (which have more internal reason to keep and ongoing traffic with IB farms)

So my question was: practically did you experience or have a clue that this impact your code ?
I am not sure it does.
But I would agree that it's pretty difficult to get such a clue.

I did set a receiving time stamp and always compare it to supplied time stamp for sake of consistencies and sometime it show a small discrepancies (< 900ms) but I always find it related to complex market condition.
Otherwise said ticks can be late (they always are but how much you accept is another issue) but not lost.
In general Tick driven algo need to be sure that you are not loosing ticks, but the time critical part will be the time to send and process the order anyway. which is > 1 magnitude slower than any tick discrepancies

Note:
In general people on this forum that are using IB ticks + simultaneously another tick provider, complain that the other one could be couple of second late. Without being a proof it's a suspicion that IB is reliable enough in general.

If your server has enough memory, running multiple TWS/IBGW simultaneously works just fine. And sharing the same market data subscription between a TWS/IBGW real and paper account is no problem either. But you might want to take a quick look at this article:

Real-time tick-by-tick data feeds and subscriptions are very reliable and completely unaffected by occasional historical market data farm disconnects. We have never experienced any gaps in tick-by-tick data feeds as long as our clients were behaving correctly. You can find several posts related to tick-by-tick data in the group archive, some of them even with performance details (such as this one).

Your questions made me curios and I ran some additional stats on our 2023 tick-by-tick real-time data feeds:

• We subscribe to 15 tick-by-tick feeds: three feeds each (Last, Midpoint, BidAsk) for five futures traded at CME in Chicago.
• Real-time tick-by-tick messages make up just under 40% of all real-time data messages we receive. The rest of the data volume relates to a number of Level I feeds plus three market book Level II feeds.

• Our virtual server is located in the east of the US in a data center with high-speed, high-availability, and low-latency networking.

So here the fun part. Year-to-date 2023 we received:

• A total of 5,931,446,980 real-time market data related callbacks. That is an average of 531 callbacks each second for all 23hr CME trading sessions this year.
• 2,287,378,131 of these were tick-by-tick callbacks (205 callbacks per second)
• The arrival time gap between adjacent tick-by-tick callbacks was less than a second for 99.94% of all callbacks (2,286,012,479)
• 99.999975% of back-to-back callbacks had a time gap of less than 10 seconds.

• And only 427 callbacks or 0.00001865% had a gap of 10 seconds or more. These are mostly callbacks that happen during the nightly maintenance window when you receive error 1100 "Connectivity between IB and the TWS has been lost" and error 1102 "Connectivity between IB and TWS has been restored- data maintained" during account resets.

In my book that qualifies for rock-stable, considering the monthly data charge is negligible.

If you do experience any tick-by-tick data interruptions, I'd suggest the following next steps: This is my interpretation of what Gordon called in a different post "Respect the basic API concepts":

• Make sure your client always uses TWS API in an asynchronous fashion. There is one or more callback for every request make sure you implement them all.
• Respecting the asynchronous nature of the API requires that your client shall never (ever ever) call sleep() for synchronization between requests and their related response callbacks.
• The API is very good at error reporting when something goes wrong. So make sure your client properly captures, handles, and possibly logs all TWS API error messages. There are three error callbacks with slightly different signatures.
• Make sure your clients perform only minimal processing on the the thread that handles the tick-by-tick callbacks. Perform any time consuming processing on or storage operations of that data on a separate thread so that tick-by-tick callbacks can always be processed right away.
• You will very likely get error 1100/1102 pairs during the daily maintenance and reset window. These are generally brief interruptions of data flow (several seconds), can happen more than once during the window, and you do not need to resubscribe your feeds. Just make sure your client is aware of these.
• Look out for error 1100/1101 pairs, since 1101 is "Connectivity between IB and TWS has been restored- data lost." and you will need to re-subscribe to your market data feeds. We have never seen an error 1101 in all those years we use TWS API, but your code should be ready to perform re-subscriptions should such an error ever be reported.

• You might get 21xx warning codes (via the error callback) that relate to data farm disconnection/connection events. They have no impact on the flow of tick-by-tick data streams and you don't have to engage any special code to keep those farms connected.

In general, reqMktData feeds seem to be quite stable and timely, too, John. Though we use them only to give context to our TickByTick and Level II data feeds, so we have less analysis for them. Keep in mind that most reqMktData feeds are aggregated over various time periods.

• The minimum delay we experience is 255ms. In other words it takes at least 255ms after the bar is closed for it to arrive in our TWS API client.
• Indeces (SPX, SPW, DJI, ...) and very liquid front month futures had average/median delays around 750ms
• Instruments with very little activity (such as futures expiring in 2024 and specialty instruments such as VXX.IV) had average/median delays around 1,100ms.
• For our mix of instruments, average/median delay for all 2,016,969 five second real time bars in June 20023 was around 960ms.

We have experienced flaky position updates in V10 TWS versions (at least in paper accounts) that we had not seen in TWS 981 before. But TWS API is not at fault since the TWS GUI shows the same incorrect positions.

Our API clients are not impacted since we have our own implementation of “Position” and “PNL”. The IBKR implementations may make sense for human traders but never worked for us (even when they are correct). Our biggest problem is that PNL resets around midnight. We work in “units” of CME futures trading sessions (17:00 to 16:00 US/Central next day) and API clients get confused when position PNL suddenly resets “around midnight”.

We have found execution reports, commission reports, and even order status updates to be very reliable and timely. Our (Java) framework is multi-threaded, entirely event driven, broken into many small focused domain classes, models, and controllers/managers. It is completely separate from and unaware of TWS API. A thin adapter layer translates abstract framework operations (such as placing orders) into actual TWS API requests. That layer also converts TWS API responses into framework events that are independent of TWS API.

Certain framework events (such as market price update events) are broadcast so that position controllers can easily maintain their own notion of current PNL. We rarely have partial order fills, but TWS API order status events and execution reports are very accurate and timely so that position controllers can adequately model reality based on streams of order state, order status, execution and commission reports, and market price update events.

The framework uses a domain/class/model hierarchy that looks something like this:

Accounts → [1:*] Account → Positions → [0:*] Position → Trades → [0:*] Trade → Orders → [0:*] Order

Our API clients never have to restart or resubscribe during the trading session in response to TWS API activities. There are, however, controlled automatic daily restarts of TWS and API clients during the one hour per day when Chicago futures markets are closed.

I agree that your order.done and order.done.wait logic is convoluted and I can see many cases where that can lead to lockups or, in case timeouts are too short, cause other issues. You might need to make your clients more event driven and put more distance between your trade decision logic, execution, and order management on one side and the actual operation of TWS API on the other side (design approaches such as “” and “”).

You need to make sure your client does not assume any order or timing of events (order state, order status, execution reports, errors), can tolerate the occasional duplication of updates, takes all events into consideration (not just order status), and does not block the TWS API callback thread.

We make heavy use of the Java built-in concurrency features from , specifically the (a Java language concept, has nothing to do with CME future contracts). I believe some of those concepts are available in Python through the .

Another good source for ideas how you can better structure your Python clients may be Ewald de Wit’s project.

But we are meandering away from the scope of this post and and the group.

闯ü谤驳别苍

?We work in “units” of CME futures trading sessions (17:00 to 16:00 US/Central next day)... TWS API order status events and execution reports are very accurate and timely so that position controllers can adequately model reality based on streams of order state, order status, execution and commission reports, and market price update events.

On Sun, Jul 16, 2023 at 04:07 PM, John wrote:

Unsure why Ewald chose to isolate the 'Inactive' state rather than adding it to the DoneStates btw.

An "Inactive" order can become active again, so it's not certain that it's done yet.

-- Ewald