¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: TWS 50/sec limit

 

Hi Franck;

Definitely, something happened with introduction of the PACEAPI feature (9.73 -> 9.74)
We've got some weird behavior with the more recent versions of TWS (> 9.73)
That's why we still use TWS 9.73 (which is very stable) but it will be decommissioned on 31th March 2022. (It will cause us a lot of trouble)

Just to give another example, about pacing issues.
When you send requests for delayed market data for a significant number of options (for which you don't have realtime subscription)

If you launch 50 requests at rate of (1 request every 50 ms); It works perfectly well with TWS 9.73
But with most recent versions of TWS; you receive data for only a subset of these instruments.
If you increase the delay between your requests, you get more responses:
At the extreme, if you wait 2 seconds between each request; it works correctly and you receive delayed market data for all the options.
But it means you retrieve the data at a very low rate...

TWS is globally a great platform and IB Services are very good. But I don't understand? that IB has not been able to address this issue. We've opened our first ticket about it more than 2 years ago...
It drives me nuts. I spent so many time explaining the case, creating tickets, providing them with samples ....?

Loic


Re: Bracket sequences not executing and a new state - Transmitted, not acknowledged.

Nick
 

¿ªÔÆÌåÓý

There have been several reports here of broken features in the TWS 10 series. Seemingly unrelated errors are happening and it feels like TWS has gotten away from them in the 10 series.

Hanging on to the 9 series as long as possible seems like the best option for now.


On 3/25/2022 6:43 PM, mark collins wrote:

Just to update in case anyone else has whack executions with 10.14. I moved to 9.83i (which is apparently still supported) and the strange statuses, the loss of bracket components and similar garbage stopped occurring. Over the last two days that whole experience? cost several thousand dollars through unbalanced trades and execution failures on requested bracket exits. Be careful, folks, IB can certainly bring fresh surprises when moving between versions.

Best wishes,

M


On Thu, 24 Mar 2022 at 17:49, mark collins via <mark.collins=[email protected]> wrote:
Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Re: Bracket sequences not executing and a new state - Transmitted, not acknowledged.

 

Just to update in case anyone else has whack executions with 10.14. I moved to 9.83i (which is apparently still supported) and the strange statuses, the loss of bracket components and similar garbage stopped occurring. Over the last two days that whole experience? cost several thousand dollars through unbalanced trades and execution failures on requested bracket exits. Be careful, folks, IB can certainly bring fresh surprises when moving between versions.

Best wishes,

M


On Thu, 24 Mar 2022 at 17:49, mark collins via <mark.collins=[email protected]> wrote:

Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :



--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Possible bug in TWS API when requesting auction price, volume, and imbalance data for ASX-listed securities

 

Hi,

When requesting auction price, volume, and imbalance data for ASX-listed securities in the pre-auction period, I'm getting the same number returned to me for both auction volume and auction imbalance, even though the tick type is different. I've put together an MWE to help anyone else look into this possible bug. I also just ran this MWE during the pre-close period today and I've pasted some of the output produced below so you can see what I mean. Anyway, the code is:
from ibapi.client import EClient
from ibapi.wrapper import EWrapper
from ibapi.contract import Contract
from ibapi.order import Order
from ibapi.order_state import OrderState

import threading
import time
from datetime import datetime
import queue
class IBapi(EWrapper, EClient):
def __init__(self):
EClient.__init__(self, self)
def request_auction_data_single(self, idnum: int, contract1: Contract):
self.reqMktData(idnum, contract1, 'mdoff,225', False, False, []) #225 is tick id for auction data of volume, price, and imbalance
return None
def tickPrice(self, reqId, tickType, price, attrib):
# tick price data sent by TWS is received by this function
attrib_as_string = str(attrib)
print("tickPrice triggered. reqId=%d, tickType=%d, price=%f, attribasstr=%s" % (reqId, tickType, price, attrib_as_string))
return None
def tickSize(self, reqId, tickType, size):
# tick size data sent by TWS is received by this function
print("tickSize triggered. reqId=%d, tickType=%d, size=%d" % (reqId, tickType, size))
return None
def error(self, id, errorCode, errorString):
errormessage = "TWS error. id = %d. errorcode = %d. msg = %s" % (id, errorCode, errorString)
print(errormessage)
def build_contract(self, mkt: str, scy: str, sectype: str, currency: str):
cc1 = Contract()
cc1.exchange = mkt
cc1.symbol = scy
cc1.secType = sectype
cc1.currency = currency
return cc1

def run_loop():
app.run()

app = IBapi()
app.connect("127.0.0.1", 7496, 0)

# Start the app in a thread
api_thread = threading.Thread(target=run_loop, daemon=True)
api_thread.start()

time.sleep(1) # Sleep interval to allow time for connection to server

# Request auction data
id1 = app.reqIds(-1)
contract1 = app.build_contract("ASX","NAB","STK","AUD")
app.request_auction_data_single(id1, contract1)


On my machine, this snippet will start printing auction price, volume, and imbalance data to the terminal for NAB (National Australian Bank) - which is one of the big banks listed on the ASX. I ran the snippet in the pre-close period today (just after 4pm Sydney time) and here is a snippet of the output produced:
tickSize? triggered. reqId=5, tickType=36, size=897951
tickPrice triggered. reqId=5, tickType=35, price=30.160000, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=61, size=0
tickSize? triggered. reqId=5, tickType=34, size=912196
tickSize? triggered. reqId=5, tickType=36, size=912196
tickSize? triggered. reqId=5, tickType=34, size=915148
tickSize? triggered. reqId=5, tickType=36, size=915148
tickPrice triggered. reqId=5, tickType=35, price=30.290001, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=34, size=915178
tickSize? triggered. reqId=5, tickType=36, size=915178
tickSize? triggered. reqId=5, tickType=34, size=915190
tickSize? triggered. reqId=5, tickType=36, size=915190
tickSize? triggered. reqId=5, tickType=34, size=916392
tickSize? triggered. reqId=5, tickType=36, size=916392
tickPrice triggered. reqId=5, tickType=35, price=30.250000, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=34, size=916618
tickSize? triggered. reqId=5, tickType=36, size=916618
tickSize? triggered. reqId=5, tickType=34, size=917042
tickSize? triggered. reqId=5, tickType=36, size=917042
tickSize? triggered. reqId=5, tickType=34, size=917851
tickSize? triggered. reqId=5, tickType=36, size=917851
tickSize? triggered. reqId=5, tickType=34, size=917863
tickSize? triggered. reqId=5, tickType=36, size=917863
My understanding is that tickType 34 is supposed to be the volume, and tickType 36 is the imbalance. However, as can be seen here, they are both returning exactly the same number each time. Note, I've verified this behaviour across multiple securities on multiple days.

Cheers all, any help would be most appreciated.

Colin


Re: TWS 50/sec limit

 

"@Frank: that's exactly the same as I'm doing it, but I'm still getting the pace violation error."

My code is MVSC C++ and my api code uses the winsock2 send function, so I know exactly when the message is sent to TWS.? It's worked with several different TWS versions.? The 1015 ms value came through trial & error, but has been rock solid.? Do you know for sure your api code is sending the message when you call it?


Re: TWS 50/sec limit

Nick
 

You need to enable the api log to see when TWS thinks the requests arrived. Your requests may not arrive at TWS at the time when you send them.

On 3/24/2022 4:56 PM, hansblafoo via groups.io wrote:
EDIT: I just made a test and I'm pretty sure that it is a bug within the TWS or the TWS API. I'm printing the time of every request sent to server and I can clearly see that I never pass the 50 msg/sec limit.


Re: TWS 50/sec limit

 

Nick, I guess that after 6 years since the original post was written, the OP doesn't care anymore. ;-) I just hijacked the thread for asking another question regarding the 50 msg/sec limit instead of opening a new one.

@Bob: I also tried your approach but when I'm requesting option chains and their data (option contract details, option prices) I still get the pace violation error. I absolutely don't have a clue why this is happening, but I'll investigate it.

@Frank: that's exactly the same as I'm doing it, but I'm still getting the pace violation error.

@´³¨¹°ù²µ±ð²Ô: thanks for providing a link, that clarifies my question. I also know this connection configuration for activating the internal pacing prevention. However, as I'm currently using an older TWS release (because of the issue requesting delayed data which only works properly in TWS releases prior 9.73), I cannot use it. Maybe it's a bug within this older TWS release.

EDIT: I just made a test and I'm pretty sure that it is a bug within the TWS or the TWS API. I'm printing the time of every request sent to server and I can clearly see that I never pass the 50 msg/sec limit. However, I just got a message that I've exceeded it by sending 180 (!) msg/sec. This cannot be true. Thus, it may be a problem with my old TWS release but nevertheless it's the only one working with delayed data. Btw, I already reported the delayed data bug to IB but still I got no response.


Bracket sequences not executing and a new state - Transmitted, not acknowledged.

 

Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Re: bunch of reqMktData requests for options

 

Hi all,

Not sure IB will address this issue soon enough (see their reply below)
I'm upset and frustrated as I raised my first ticket about it more than 2 years ago;

---------------------

Dear Sir,

I haven't received an update from the development team, but I have asked for updates or progress reports. Please keep in mind, because this concerns delayed data and not live data, our developers might not view it as the most urgent, and for that I apologize. I will continue to ask for updates so they may review this further, and will let you know of any updates as soon as I have them.
Regards,
xxx
IBKR API Support


Delay of about a minute or so for the API orders to show up on TWS

 

Hi Nick,

You could be right about certain instruments - an SQ short STPLMT filled exactly as it should this morning.

Thank, as always, and Be Well,
Lou Dudka


Re: Delay of about a minute or so for the API orders to show up on TWS

Nick
 

¿ªÔÆÌåÓý

Valid point. There are enough active traders here that anything widespread would probably get a mention.

It could be something affecting only certain instruments.

Hope it all goes back to normal for you.


On 3/24/2022 11:53 AM, Lou Dudka wrote:

HI Nick,

I agree that not to much emphasis should be placed on paper trades.

However, in all my experience over the years, IB paper has been a fairly accurate barometer of live trading.

I'm only noting this because I feel IB made some changes that are affect others ....

Thanks, as always, and Be Well,
Lou Dudka


Delay of about a minute or so for the API orders to show up on TWS

 

HI Nick,

I agree that not to much emphasis should be placed on paper trades.

However, in all my experience over the years, IB paper has been a fairly accurate barometer of live trading.

I'm only noting this because I feel IB made some changes that are affect others ....

Thanks, as always, and Be Well,
Lou Dudka


Re: Delay of about a minute or so for the API orders to show up on TWS

Nick
 

¿ªÔÆÌåÓý

Everyone has different experiences but I don't think you can make meaningful connections between fills on paper account and live. You just don't know what would have happened on live.

If you are seeing a paper account behave different than usual it might mean something, but again, doesn't tell you what would have happened on live.


On 3/24/2022 11:37 AM, Lou Dudka wrote:

And yes, the order is for 2300 shrs, but I should've received at least a partial fill.

Am I in error?


Delay of about a minute or so for the API orders to show up on TWS

 

And yes, the order is for 2300 shrs, but I should've received at least a partial fill.

Am I in error?


Delay of about a minute or so for the API orders to show up on TWS

 

Here's the jpg attachment of the 5 sec chart.


Delay of about a minute or so for the API orders to show up on TWS

 

HI All,

I experienced a no-fill (as of now) on the paper trading system today on a STPLMT bracket entry order:
OSTK 2330 Shrs short TRIG: 48.22? LMT: 48.22

The trigger fired at about 9:40 AM and hasn't filled, though it looks like it should.?

Not a big deal, since is paper, but a bit concerning bc of problems others are having ...

Thanks, as always, and Be Well,
Lou Dudka


Re: Delay of about a minute or so for the API orders to show up on TWS

Nick
 

The first step is to enable api logging and look to see when the order arrived at TWS. This will give clues as to whether the issue is in TWS or on the client side.

On 3/23/2022 9:16 PM, Ketan via groups.io wrote:
On live account, today, I experienced API order not showing up on TWS for quite some time, and by which time, the targeted price moved away.

And similar order, entered through TWS interface executes right away.


Re: Connection disconnects immediately after connect with PACEAPI enabled

 

¿ªÔÆÌåÓý

Waiting for the nextValidID callback before calling other API seems to have fixed the issue.? Thanks for your help.


From: [email protected] <[email protected]> on behalf of ´³¨¹°ù²µ±ð²Ô Reinold via groups.io <TwsApiOnGroupsIo@...>
Sent: Tuesday, March 22, 2022 8:17 PM
To: [email protected] <[email protected]>
Subject: Re: [TWS API] Connection disconnects immediately after connect with PACEAPI enabled
?
Crow,

the issue with your code is not the .setConnectOptions("+PACEAPI") call. It is rather the location (timing) of the reqPosition() and reqMarketDataType() calls.

You might want to reread the section in the API Reference Guide. You should not send any request toe TWS API until you have received the BApi.EWrapper.nextValidID callback. That is your indication that all API components have been initialized properly and messages can flow in both directions. Your code calls reqPosition() and reqMarketDataType() before that callback has arrived.

There are other areas that can be improved. The ApiContoller.java file in the IBKR API distribution is a very good example of how you might want to structure your interface with the TWS API.

´³¨¹°ù²µ±ð²Ô


Delay of about a minute or so for the API orders to show up on TWS

 

On live account, today, I experienced API order not showing up on TWS for quite some time, and by which time, the targeted price moved away.

And similar order, entered through TWS interface executes right away.

Please share if there are ways in which to mitigate latencies from API to TWS.

Thanks,

Ketan


Re: Re-login failures with TWS auto-restart option.

 

Hi ´³¨¹°ù²µ±ð²Ô,

Thanks for the reply!

I'm running stand-alone older TWS version Build 981.3c, Jun 29, 2021.? Win7. Old dual-processor Lenovo E545, 12GB RAM, 256GB SSD.

It's not a deal breaker since I'm usually around to check.? I'll keep you updated if it happens again, especially this week.

Thanks, as always, and be well,
Lou Dudka