开云体育

I always connect to IB through the TWS python API. We run TWS itself on a server; the python code runs locally on my PC.? Until recently, establishing a connection to IB this way took <2 seconds, and was usually almost instantaneous.? For the past couple of weeks, though, the time required to establish a connection has ranged between ~30 seconds and a whopping ~4 minutes.? The TWS running on the server has also started using about twice as many resources as it used to.?

Nothing has changed on our end, apart from the recent dramatic cold snap, which hit extra hard here in TX.?We've checked and rechecked our system and code, and found nothing. We've also scaled back the amount of data we're requesting from IB, with no improvement resulting.? (I already had several measures in place to make sure I wasn't hitting IB with too many requests at a time.)

Is anyone else suffering slow connection times?? Is my crazy idea that some parts of IB's infrastructure (or key employees) were affected by the cold snap as crazy as it sounds to me?? Or is it something simple like needing to update my TWS?? (I can't easily check my version right now, but it's ~6 months old.? We like finding a nice stable version and sticking with it for a while, which is why we haven't tried that yet as part of our troubleshooting.)

Already done, and it connects no problem to that, although it's a more updated version--978, whereas I think the server's version is 976.

Thanks--we've checked our network pretty thoroughly, although we'll continue to check anything else we can think of, like making sure there's no excess traffic we've forgotten to take into account.?

To further stump me, today about half of my scripts connected in less than a second--less than .1 in some cases--and the other half took >30 seconds.? improvement, but still mystifying!? My best guess is still that _something_ happened on the IB side, but if no one else is having similar problems...

Since the tally of folks that have the same issue seems to be approximately zero, IB having an issue feels unlikely, though not impossible. So let me briefly raise three things that I'd look at if I'd have to trouble shoot API connection issues.

[1] Stale API connections:
We once wrote a simple "Is my TWS alive and actually connected to IB" monitor that would connect to TWS, do a simple operation that requires TWS to communicate with IB, and then disconnect. The monitor was started automatically and frequently but somehow caused stale (not completely closed) API connections to build up. When you click "DATA" to get the connections listing in TWS, do you see stale API connections from past script executions? Those did cause connection request delays, in my case, even when TWS was far away from the maximum number of API connections.

[2] DNS reverse lookup:
You said you checked the network on your server, but did you check DNS as well?

• Have you experienced any sluggishness (even briefly) for regular commands on your server? Assuming it's a Linux system, even commands such as "ls -l"
• Does "netstat -a" or "lsof" hang for a few seconds but "netstat -an" or "lsof -n" do not?

Several library functions unexpectedly perform "reverse DNS lookups" and can block the caller (in this case the thread in the Java JVM that handles your incoming API request to TWS) for extended periods of time until failing DNS lookups succeed or time out. If your internet service provider has any instability with reverse DNS lookups, otherwise perfectly fine servers can have operations seemingly randomly freeze for 20 to 30 seconds.

[3] How are your entropy levels?
This is a little stretch but fits the symptoms you are having if you are running some kind of Linux system. And it took me weeks to figure that out on a server I had in a data center in Dallas (though this is not specific to Dallas or Texas)

In order for strong SSL encryption to work, the Linux kernel collects "truely random events" and builds up a buffer of entropy that Java JVMs (and other programs such as sshd, httpd, ...) access through the /dev/urandom device. And while only very few bytes are needed each time, opening or reading from /dev/urandom when the buffer is low or empty will block the caller until enough entropy has been collected. And the Java JVM frequently opens /dev/urandom when various network related operations take place.

You can read up on this with "man urandom" and check your server's entropy level with "cat /proc/sys/kernel/random/entropy_avail"

Hope this helps.

I believe I may be having a similar issue.? Just started this morning though first time I've ever seen it.? Also connecting via TWS Python API but I am running everything locally on my computer. When I call the connect method I get no response for about a minute then it produces this traceback from the source code.? Haven't changed any of my code for about 2 weeks and I've been able to repeat this error a few times.? When I go to TWS data it does not show my local connection.? This is also intermittent, and rebooting my computer seems to fix it.

Can't help you with Python, but you might want to consult a "second opinion" in the form of a different API (Java, C, Csharp) to see wether it is TWS/network/IB related or some issue with the Python API.

The API distribution, for example, contains a few already compiled programs such as IBSampleApp.exe in case you run on Windows or the OS independent Java demo app jar.