开云体育

Regarding the 50 msg/sec TWS rate limitation, is IBKR checking it by calculating a continuously sliding window, or are they doing a nonoverlapping time window? The first is stricter.

?

If it's the second one, then theoretically you can send up to 100 messages in? a short burst. As long as the first fifty were near the end of the first window, and the next 50 were at the beginning of the next window.?

?

If this was an option, then there would be the challenge of trying to figure out where TWS' clock was. Does anyone know if the calculation is made in TWS before orders are sent out over the wire, or are the calculations made upon receipt at the data center?

Have you seen how IBKR describes it themselves: ?

Nowadays you don't really need to worry about it any longer as the API has a built-in message pacer. Its task is to prevent you from going to fast: it will buffer the messages that exceed the limit.

It sounds like you both are talking about the +PACEAPI thing. I want to turn that off and manage everything myself.?

250/5 sounds promising. I’ll poke around and report back with my findings.?

Before we start, a few disclaimers and initial thoughts:

• The actual implementation of the TWS/IBGW built-in API request pacing is undocumented and technically not part of the API. It can change at any time without notice (and has) but has been stable for years and permits sustained request rates of at least 50/sec for extended periods of time. So you can make 250 requests in 5 seconds.
• The TWS/IBGW API request limit relates only to reqXXX() calls by the clients (e.g. messages from the client to TWS/IBGW) and not to the response callbacks that result from those requests. For example, with multiple simultaneous real-time market data subscriptions for busy instruments (especially with TickByTick and Level II), I see callback rates for extended periods of time of well above 10,000 response callbacks per second.
• The API request limit is applied to the combined rate of requests for all clients simultaneously connected to the same TWS/IBGW. Implementing your own pacing scheme needs to take that into account and may have to coordinate the request rates for multiple clients.
• It may be possible for some simple work loads to exceed the 50 requests/s limit for brief peak times considerably (see below), but it will be a fragile undertaking with the risk of being disconnected by TWS/IBGW at will. ?It feels like you will waste your time and you should stick with auto-paced connections with TWS/IBGW.

With that said, here some observations from a few quick tests with one of my system test tools against stable TWS 10.30.1u. The tool makes a configurable number of reqContractDetails calls at the fastest possible pace and monitors and tallies the resulting responses and errors. In order to focus on the connection between the tool and TWS/IBGW, all requests are made for the same instrument. That makes it possible for TWS/IBGW to respond with a locally cached ContractDetails object and minimizes the need for communication between TWS/IBGW and the IBKR infrastructure. This is an artificial work load and you cannot expect that the results I present work for more complex tasks such as order placement.

When the test tool (client) is configured to exceed the allowed rate significantly, TWS/IBGW send up to two "error #100 - Max rate of messages per second has been exceeded” and disconnects the client if the rate is still exceeded after the second error message. It takes approximately 500ms from the start of the test run for the first error and another 500ms for the second error, though times differ between runs considerably.

In my setup and with a sequence of reqContractDetails calls for the same instrument, a rapid fire of 750 requests causes two error messages but no disconnect, while a run with 1,000 requests causes disconnects. Below a couple charts that show the timing of requests and responses for seven runs. This was not a controlled experiment just a few runs on two different client computers (one co-located with TWS in the same Linux instance in the cloud and one running remotely in my development environment with Wi-Fi, cable modem, competing with other traffic, ssh tunnel, ..) and during different ?times over the weekend (more quiet times earlier on Sunday as well as runs after 17:00 US/Central when futures were trading in Chicago already).

Here some highlights:

• It took the faster (client) computer in average 62ms to fire off 750 requests (82us per request). The slower computer took 146ms (195us per request).
• TWS responded with a first "error #100" within 500ms to 600ms after the start of the tests. By that time, all requests had been fired off "long time" ago.
• The second "error #100" arrived between 1,000ms and 1,600ms after the test start.
• All 750 requests resulted in a contractDetails() and a contractDetailsEnd() callback within an average of 2.4 seconds (min 1.4s and max 3.5s)
• Run #2 is an outlier for request time (slower computer) and run #3 is one for the response times (slower/higher latency network between TWS and IBKR).?

Again, don’t expect that you can extend this very artificial benchmark to any serious and meaningful work load.

闯ü谤驳别苍

?

?

?

On Sun, Mar 2, 2025 at 09:21 AM, <tbrown122387@...> wrote:

Thanks Jurgen. This is very informative. So turning +PACEAPI off, gives me a little wiggle room. Got it. I am more interested in the ability to revise orders with placeOrder(), but as you mention there will always be plenty of caveats with this sort of thing.?

To disable auto pacing, don't send "+PACEAPI" during client connection AND select the option "Reject messages above maximum allowed message rate vs applying pacing" in the global API configuration in TWS or IBGW.

?

?

?

On Tue, Mar 4, 2025 at 02:00 PM, <tbrown122387@...> wrote: