Generalized Two Exchange Latency Model

Got some time before I have to go tend the fantasy bball team mired in the middle of the dogpile. This a generalized two exchange trade crossing model. The generalization to more than two exchanges is straightforward.  

Here, in the DynaPie Latency Model Figure (below),  we have represented two colo installations. The first colo contains Exchange EX1, Gateway GW1, and Client Server CL1. The second colo similarly contains an exchange, gateway, and Client server (EX2, GW2, CL2). The Client Servers run the relevant exchange protocols to perform order execution via respective broker dealer gateways and solicit current market data from each exchange locally.  To simplify the analysis we assume all latency is accounted for in the links, and for example, the portion of the gateway latency not accounted for in the link latency is negligible. The market data and client to gateway Link latency, represented by the variable L, is equal to a constant C. We assume the latency for any link within the colo is a constant. If you worry about this, you can assume C is the longest latency measured on average over a sufficiently large sampling period of all links within a single colo installation. The client, via the colo gateways, has two order entry options. CL1 can send a new order (wlg any other message) to EX1 via GW1 or send a new order to EX2 via GW1. CL2 has symmetric corresponding order options via GW2. The latency to submit a new order within the colo is C as previously discussed.  The latency cost to submit a new order  from GW1 to EX2 is ax+b, where a and b are constants and x is proportional to the minimal transmission line latency connecting GW1 and EX2. Similarly the latency between GW2 and EX1 is ax+b (we assume the same transmission lines, nics, and switch connecting the gateways and exchanges). Finally, the latency between the two client servers is represented as dy+e where d and e are constants and y is proportional to the minimal  transmission line latency connecting CL1 and CL2.

 

Figure: DynaPie Latency Model

 

 

 

This model is useful because it represents the crossing opportunities between LN  and NY for vanilla interest rate swaps,  NY and Chicago for basis trades,  and wlg Weehawken and Carteret for Equity and ETF. The internal colo latencies are independent (we are representing them as constants) of the distance between the colos.

 

We know from previous DynaPie posts that it is optimal for the client server to move between colo installations for both market data collection and order execution. In this case we are assuming no movement and all market data collection and trade execution happens within some colo installation. 

 

With this model framework there are several interesting questions:

 

1. if L= ax+b = dy+e is it ever profitable to allow the gateway to route an order to a non-colo exchange? I think the answer is obviously no, but that is just a guess.

 

2. If ax+b >> dy+e how much more profitable is it for the client to route their own orders? Don’t know but this is a practical question as the client servers can be connected by 40GB links w DMA versus the 10GB  gated links to the exchanges. 

 

3. Is there even any reason for the Gateway to route outside the colo? Pretty sure the answer is no, maybe HA ?

 

4. Given the nature of the analytics/computation executed at the Client Servers how does one best hide latency l=dy+e? Presumably the latency overlap  techniques change with the magnitude of dy+e. The client computation crossing equity between London and NY is very different than crossing Carteret and Weehawken.