Comment by chollida1 | Hacker News Reader

Comment by chollida1 | Hacker News Reader

Parent Full thread

> Why would you want to place the server in the center?

Because for arbitrage you need to know the price in both area's before you can react. If its instantaneous at the collocated site and 5ms to get to your other machine, you need to wait 5ms to act and then add about the same time back on to send your order to the further location.

If your machine is in the middle then you only need to wait 2.5ms to act and then add about 2.5 ms to send your orders.

This type of arbitrage is much easier if all orders originate from one machine( as opposed to each collocated machine sending its piece of the stat arb order.

If you have 2 machines sending their own parts of the arb order then you have to sync them if one fails to get its side of hte order, and hence more latency.

EDIT in case I wasn't clear, the benefit is having one machine do the arb instead of two machines sending simultaneous orders. This way the two machines don't need to sync up to determine if one leg was done and one leg was hung. All the information is in the same program on the same machine so there is no distributed state to reconcile.

No. The parent suggests having 2 machines (1 at each end), but each trading order would be issued by only 1 machine (not 2). So there is no synchronization issue.

Example: machine A instantaneously become aware of some event at exchange A. It sends an order to remote exchange B (which takes 5ms) and at the same time sends a matching order to exchange A. Total time = 5ms, which is the same as having a machine in the middle having a latency of 2x2.5 = 5ms. [Edit #1: I edited this sentence to reflect the fact the algo sends the matching order immediately to the local exchange.]

So I still don't understand why is there any advantage in having a computer in the middle.

Edit #2: you wrote an edit ("This way the two machines don't need to sync up to determine if one leg was done and one leg was hung. All the information is in the same program on the same machine so there is no distributed state to reconcile.") which I think finally clarifies the advantage in having a computer in the middle. You don't run the risk of the 2 computers at each end executing orders that conflict with each other.

A signal for this type of trading requires knowledge of the bid ask in both locations.

You do: that's the signal that's sent over in 5ms. You then combine it with the local price 5ms ago, and you can construct the exact same instruction the computer in the center would have come up with 2.5ms ago, based on the price in both locations 5ms ago.

Both sides can this way make identical decisions to eachother, at the same time, and identical to those that would have been made by a computer in the center.

In my scenario, a machine knows the local exchange price as of 0ms ago (instantaneously) but knows the remote exchange's price as of 5ms ago.

You are saying it is better to know exchange A's price as of 2.5ms ago, and exchange B's price also as of 2.5ms.

But why? Either way you are ignoring 5ms's worth of trading activity. Either 2.5ms on both exchanges, or 5ms on one exchange.

Edit: I think I understand the advantage - see my edit #2 in my post above.

You can't wait to hear back from the other exchange and see that the leg is available, "pure" arb teams in HFT typically quote on both products of a pair (e.g. cash vs futures FX), at favorable prices (e.g. I'll quote a bid at X on A if I can aggress at >= X/the implied price of X on B) and turn around and hit the other product as soon as they get filled. Sometimes they'll miss, so they're really running stat arb strategies, but that's the closest you'll get to pure arb in this space.

Reply on news.ycombinator.com