Keyboard Shortcuts
Likes
Search
Re: TWS 50/sec limit
All, I did extensive work with this java client and found it very frustrating. I first added an expiration date to the contract definition and it began to work. This confirmed that the request exceeded the limits. Then I created an elaborate (for me as a novice programmer) procedure to find the ATM strike and then figure out how far OTM I wanted to request. Then I was able to just put in a short sleep and change the expiry date to the next week in a loop and started to get some useful parts of the chain. The weakness to this is that I had to hardcode the expiry date and like today and next week, it's not always on a Friday. All of my work was tested using the demo acct so all this might not mean much. The original poster is correct that IB wrote the client GUI and it is poorly designed regarding the option chain implementation. Patrick On Dec 24, 2015 11:21 PM, "Dmitry Shevkoplyas shevkoplyas@... [TWSAPI]" <TWSAPI@...> wrote:
> > ? > > @Nick news1000, > > I'm not sure how important it is, but the above exercise with java demo app > also shows that it is actually TWS who initiate the disconnect when client > brakes some rules (number of realtime subscribed tickers or exceed request > rate limits). > > So then statement "Disconnects are caused by an error in your program." > seems to be not 100% right since there's no language/functionality scope > error - I mean the program itself is clean and does not crash nor does it > any wrong calls, but rather logical error (pacing) related to timing can > occur due to some reason ant then disconnect will be caused by TWS. > > And then 2nd statement "TWS does not disconnect for pacing violations." is > not true. What I saw in described java demo app was: > > *case-1: requested too many contracts simultaneously* > TWS does disconnect client when it brakes a limit (number of simultaneously > subscribed tickers). > TWS also brings nice modal popup alert with explanation as of why you've > been kicked out :) > > *case-2: sent too many requests/second* > Then to check if similar disconnect (by TWS) happens in case of request > pacing I modified the demo app to send some bulk (about 950:) > reqContractDetails and saw similar behaviour: client kicked out by TWS > after 3 error/notes: > > Max rate of messages per second has beein exceeded:max=50 rec=83 (1) > Max rate of messages per second has beein exceeded:max=50 rec=85 (2) > Max rate of messages per second has beein exceeded:max=50 rec=83 (3) > disconnected > > D > > ps: case-1 sometimes does not kick client out (if I subscribe to few > hundred of options with rate less than 50 per second to avoid pacing), but > I only tested it once around 1am eastern, so inconsistency may be due to > "funny time". > > On Thu, Dec 24, 2015 at 2:43 AM, Dmitry Shevkoplyas <shevkoplyas@...> > wrote: > > > > Confirming: java demo client loses connection when "Options" -> "Option > > Chains" tab used to get all calls/puts for "IBM". > > > > But it is just a poor design/implementation of java demo application > > itself. > > > > *Short description* > > When option chains coming back from IB each of contract added into new > > table row and then request for market data for that contract fired by java > > demo app right away. Obviously since there are hundreds of options for IBM > > the above logic creates a few problems by completely uncontrollable > > requests rate along with an attempt to subscribe to uncontrollable number > > of tickers (more than 100 in our case, which is well known > > poor-man-IB-imposed-limit:) > > > > *Long description aka how to reproduce:* > > > > Download and install the latest stable TWS: > > on my mac I end up with this installer file: tws-stable-macosx-x64.dmg > > MD5 (tws-stable-macosx-x64.dmg) = 38e3c828d2939752e34af3bd8fd60df4 > > > > Get latest stable IB API by visiting: > > > > "IB API for Mac/Unix" Version: API 9.71 Release Date: April 24 2015 > > MD5 (twsapi_macunix.971.01.jar) = 6b8ed9a34a38d7bab329f2c533d478f3 > > > > # extract files: > > jar xf twsapi_macunix.971.01.jar > > > > # then follow this doc to run it: "Running the Java Test Client Sample > > Program" > > > > > > > > run java demo app > > click "options" tab and leave default values (IBM) > > > > click Go, after about 1-2 sec there's couple tables (Calls and Puts) > > populated and in the log window of demo app we see that we're actually got > > disconnected! > > > > TWS will show following window: > > You have requested data for 106 contracts simultaneously, which exceeds > > your account current limit of 100. You may bla bla. . . > > [image: Inline image 1] > > > > Btw, java app will not get disconnected if we select "Use snapshot data" > > checkbox. > > If you wonder why, see this passage in the OptionChainsPanel.java file: > > > > (quote) > > if (snapshot) { > > Util.sleep( 11); // try to avoid pacing violation at TWS > > } > > > > (end of quote) > > > > the above lousy "sleep" is in milliseconds, which means it wont allow to > > send more than 90 requests per second and it might work for some simple > > solutions. > > > > good luck, > > Dmitry > > > > > > On Thu, Dec 24, 2015 at 2:17 AM, tron001@... [TWSAPI] < > > TWSAPI@...> wrote: > > > >> > >> > >> If you connect via IB Gateway instead of TWS, you will be able to make > >> about 120 requests/sec (don't have the exact number right now). > >> > >> > > > > > > > > -- > > §ã §é.§Ô§Ý.§å§Ó., > > §¥§Ú§Þ§Ñ §º. > > > > Dmitry's > > <> > > TWS API FAQ <> > > > > > > -- > §ã §é.§Ô§Ý.§å§Ó., > §¥§Ú§Þ§Ñ §º. > > Dmitry's > <> > TWS API FAQ <> > > > > |