[ts-gen] Keeping TWS/shim up for an entire week?

Ken Feng kfmfe04 at gmail.com
Mon Aug 17 18:02:02 EDT 2009

Hi Russ,

You are right.  Forex is different.  One of the reasons I prefer IB
is, unlike other forex brokers, as a matter of policy, they do not
take the other side of the trade.  As far as IB acting as the
counterparty for a forex trade, I am not sure, you may be right on
this - outside of the futures market, brokers probably act as the
counterparty for most trades, and they can do so without risk (if we
ignore credit risk) if they act as counterparty to both sides of the

Thank you for your caveats and detailed descriptions.

> 4.  The shim will use up to 8 overlapping (as to
> subscriptions) connections to a single TWS; A second ISP
> connection, and second TWS account are not difficult to set
> up.  Call these TWS A and TWS B, and vary the restart time of
> A and B daily, and re-establishing shim A (to TWS A), and shim
> B (to TWS B) at will, but in a fashion that there is never
> interval of a complete dropout of a shim talking to a live
> TWS.
> 5. There is no problem running two TWS listening on two
> different ports, on a single Linux box; similarly, there is no
> problem running multiple shim's on a single Linux box

These two suggestions are quite good - first, I will try to get my
code to robustly keep one line up as much as possible, and then I will
consider building in redundancies.

> You have [re-]established that there is a middle of the night
> temporary outage of the TWS being able to 'unreach' its next
> hop at IB central; this comports with prior reports.
> Suggestions exist on the Yahoo that the 'location' that an
> account connects to may be varied on request to IB customer
> service (US CT, Switzerland, and Hong Kong data ceners, as I
> recall), for a second account

This is very good to know.  Since I am located in Tokyo, HK is likely
my data center - a second account is a good idea.

> One assumes that the counterparty, whether IB or another
> vendor, does not inadvertently expose arbitragable events
> against itself, in this special case of non-exchange based
> forex.  [It may or may not be the case that IB as the next hop
> broker does not take away all subsequent arbitragable events
> (viz., follow, so as to functionally frontrun, after a 'first
> trade' points out such an opportunity) -- one cannot watch
> everywhere all the time with the same degree of intensity]

I assume the latency and connection quality is insufficient for true
forex arbitrage, even if, somehow, such opportunity existed for retail
traders.  There are many technical issues regarding latency, race
conditions, legging, etc, the shorter the trading time frame.  That's
a no-go-zone given the IB/TWS setup.  However, the shorter term we go,
the more it resembles this type of trading.  My preliminary findings
suggest that IB/TWS/shim is probably good enough to trade right
outside of these time frames.  I will let you know if this observation
holds over time.

About an hour ago, 20:59:55UTC was the "last tick of the day" for
forex.  The "first tick of the day" appears to be 21:15:00UTC.
Matching what I observed over the last couple of weeks, TWS/shim ran
smoothly without a glitch.  Ticks stopped coming in for the TWS GUI
and shim waited for additional ticks to come in later on.  The actual
forex market obviously did not take a time-out.  If I can get TWS/shim
to act this way for the entire week, I would be happy.

I suspect TWS/shim is rather robust, if I can figure out how to manage
the states/responses that are coming out of TWS.

Thx for all your input.

- Ken

More information about the ts-general mailing list