Live data from Hacker News

Thoughts on low latency trading if exchanges went full cloud

blog.abctaylor.com

151–160 of 184 posts

Re: Thoughts on low latency trading if exchanges went full cloud

#151

It's my opinion that stock exchanges should batch trades every 30 seconds, or longer (depending on the market), so that millisecond arbitrage becomes impossible. Front running the market in any manner should be illegal.

Yes. There is actually some research into this idea where markets would effectively conduct rolling auctions, but I'm struggling to find it at the moment because I'm in a work meeting. Iirc the evidence suggests this would reduce market dislocations when news comes out etc so would generally improve price discovery.

Markets already conduct an opening and closing auctions and conduct an auction to resume after a volatility break (what people often call a "circuit breaker" in the press although it's a volatility break) so this would not be as much of a technological lift to implement this as it may appear.

How it works from a practical perspective is the exchange suspends matching for a period (so say 30mins) but order placement still works. Then when the market comes out of suspension a single print runs to uncross the order book, and everyone who submitted an order which matched gets executed at a single price. So as you say timing arbitrages of the current kind are effectively impossible. So in the case of a rolling auction you would do that print and then immediately suspend matching again and do another auction.

Here's some background on how auctions work in financial markets in general but it's not the specific paper I was referring to https://www.princeton.edu/~jkastl/auctions_finance.pdf

Re: Thoughts on low latency trading if exchanges went full cloud

#152
post #85

Earlier quoted context omitted.

> Knowing you can saturate your entire network with 10G traffic and every participant will get the same market data packets at the same time[0] Hold on a second. Multicast is nifty, but it does not perform miracles. If you operate a 10G multicast network and actually saturate it, you will experience drops and buffering-induced delays. Perhaps you can play games with time-synchronous networking, but as far as I know t…

People get weird about the word “saturate”. I think GP is switching to “max sustainable” and expecting everyone else to come along for the ride. Queuing theory has many many bad things to say about actual saturation.

add "carrier sense multiple access" packet creation

Re: Thoughts on low latency trading if exchanges went full cloud

#153
post #54

The biggest current limitation with cloud providers when it comes to exchange tech is the lack of real multicast support. It is rare outside of exchanges, but extremely low latency L1 multicast market data has become the backbone of exchanges, both for fairness and for scalability. Knowing you can saturate your entire network with 10G traffic and every participant will get the same market data packets at the same tim…

Unless you build your network for it, multicast is a huge pain in the ass to administer. None of the big cloud providers built for it at the scale that traders use it, and I think they prefer things that way. When customers want it, they all just fake it by doing fan-out unicast.

All hyperscalers have an SDN that essentially spoofs local ARP/DHCP inside the hypervisor and does not support broadcast or multicast by design (there are some caveats here, since some telco protocols that require them can be made to work).

Re: Thoughts on low latency trading if exchanges went full cloud

#154

I used to work in machine maintenance, so I always think about what will happen when the machines involved fail. NYSE machines hosting the trading server fail: presumably they have hot backups they're ready to switch to but that takes time and will interrupt trading during the cut over. Not to mention that not all failures are hard failures, what if the NIC is downtrained to a lower speed, RAM is slower than it shoul…

They literally have triple hardware redundancy. They can afford it.

Re: Thoughts on low latency trading if exchanges went full cloud

#156

Earlier quoted context omitted.

The claim is they play marketmaker (they hold stocks for short periods of time so your trades execute faster), they obviously want a profit incentive for doing so.

That begs the question by assuming that trades executing faster are a good thing to optimize for. Is the stock market for investing in a company, or for extracting money from momentary fluctuations? Those seem to be mutually exclusive.

> Is the stock market for investing in a company

With the exception of the IPO and buy-backs, the stock market is NOT for/about investing in the company.

When you buy IBM on NYSE, IBM doesn't get anything. Similarly for selling stock. If IBM doesn't see any money from a trade, how is that trade an "investment" in IBM?

Stock trading is trading partial ownership. That's very different from investing.

In other news, there's no money in the stock market. The money that you pay for IBM stock does not go to the "stock market". It goes to whomever owned the stock that you bought.

Re: Thoughts on low latency trading if exchanges went full cloud

#157

Earlier quoted context omitted.

I'm curious if you know what, at a switch level, would actually cause drops and buffering for a 1:N (near-) saturated multicast flow. If all the packets are coming from the same source machine at (perhaps) 9.9Gbps and flowing into the switch, I would expect the switch to robustly redirect all that data with near-zero latency or packet drops to all its output ports. I don't think 10G Ethernet has "backpressure" in a w…

Periodic background traffic like DHCP and background noise causing packet loss. You can’t run a queue at 100% and have any expectations of latency. In fact the rule of thumb from queueing theory is 50% to avoid latency spikes.

I mean it's not that hard to eliminate all other traffic on a closed network like that, at least where there's millions of dollars at stake.

Must be nice to open Wireshark and see _nothing_.

Re: Thoughts on low latency trading if exchanges went full cloud

#158

Earlier quoted context omitted.

They already do this for the opening and closing auctions. You can have a market-on-close order or limit-on-close order for example. The market on close orders are guaranteed to fill. The limit orders are filled using price-time priority, so best prices submitted earliest fill first, after the market price orders. I guess it is possible that there are remaining marketable orders that never fill because of an imbalanc…

If you keep price/time priorities you still get a race to pile into new levels after the previous batch.

[deleted]

Re: Thoughts on low latency trading if exchanges went full cloud

#159

Earlier quoted context omitted.

They already do this for the opening and closing auctions. You can have a market-on-close order or limit-on-close order for example. The market on close orders are guaranteed to fill. The limit orders are filled using price-time priority, so best prices submitted earliest fill first, after the market price orders. I guess it is possible that there are remaining marketable orders that never fill because of an imbalanc…

If you keep price/time priorities you still get a race to pile into new levels after the previous batch.

That's what happens with the opening and closing auctions currently.

Re: Thoughts on low latency trading if exchanges went full cloud

#160
post #22

This is an interesting read but I think it leaves outside what kind of trading is the one that would benefit from ULL. ULL and currently HFT seems to be very useful for market making (buying the ask and selling the bid and profiting from the bid-ask spread making parts of a cent per transaction, done a few million times a day), but there are other uses for HFT. One of them would be to execute very big orders over tim…

Your description of market making is backwards. If you're buying the ask and selling the bid, you're paying the spread not collecting it.

Thanks for the correction!
Post reply on HN