Live data from Hacker News

Thoughts on low latency trading if exchanges went full cloud

blog.abctaylor.com

161–170 of 184 posts

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

#161

Earlier quoted context omitted.

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.

Yep. They are more latency sensitive than the continuous portion of the day.

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

#162
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…

Generally speaking how multicast is used in trading situations[1] is you have two networks. On the primary network you do most of your normal IP traffic between applications etc. Then you have a seperate marketdata network that has most of the multicast traffic and it's exclusively used for marketdata. Marketdata generally is delivered on an "As fast as possible" basis[2]. So you don't care too much about occasional…

I’ve seen some multicast market data protocols with remarkably poor ability to detect or recover from drops. And they are very much not of the form where a newer datagram supersedes the older one.

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

#163
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…

Here is a research paper I recently wrote about a fair and scalable multicast in the cloud: https://arxiv.org/abs/2402.09527

I would love some feedback!

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

#164

Earlier quoted context omitted.

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_.

That would be highly uninteresting to the rest of us don’t you think?

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

#165

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.

10-100 millisecond auctions have been proposed seriously. 30 seconds is pretty long. If you would like a counter-argument, the options markets essentially trade on an auction basis: every time someone* sends an order that crosses a spread, there's an auction that does price discovery of the security. That does not promote having narrow spreads or transparent prices - options markets have huge spreads even for very liquid products.

*someone who is not a market maker

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

#166
post #124
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…

Are people still using 10G in PROD? I thought 40G and 100G had generally replaced that. I have 10G cards in my homelab that are a decade old and cost less than $100.

10G serialisation delay is lower than 40G or 100G.

Most markets can disseminate their feeds on 10G effectively. This isn’t true of the major US exchanges.

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

#167
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…

I find it sad that equal access between the entities doing HFT and regular Joes is not required for fairness, but god forbid one HFT having some milisecond advantage over another. That would be unfair. Can't have that.

Regular Joe is so bad at trading stocks that hedge funds literally give him a discount on the national best bid/offer for the privilege of being allowed to trade with him.

Giving retail traders access to the "actual market" would most likely result in worse execution on average, according to some studies.

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

#168

Why would the exchanges want to move their colos into the cloud. They've spent the capex and they can charge lots of money to rent data center space, cross connects and other services to their customers. If they moved to the cloud, all that revenue would go from them to AWS/GCP/etc. Doesn't seem like a profitable move for the exchanges. They make more $$$ with on prem setups.

Somebody needs a project to get promoted …

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

#169

Earlier quoted context omitted.

In the United States at least both scenarios you mentioned are illegal. Market makers are not just sitting in the middle of orders. They buy without a seller lined up and then fill orders from their own inventory (or route orders to an exchange in the case where they can't fill a buy order from their own inventory). In cases where they route to an exchange they are required by law to fill the order at the lowest pric…

Latency Arbitrage still exists in a world with NBBO regulations. Research consistently finds that not only does the strategy work in theory, but that it is consistently put into practice by HFT firms to the detriment of other market participants. If a firm can calculate the NBBO ahead of other market participants and the market regulator, it can still legally front-run the market, and risklessly extract rents from en…

The cause of latency arbitrage is not HFT, it is the fragmentation of liquidity.

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

#170
post #162

Earlier quoted context omitted.

Generally speaking how multicast is used in trading situations[1] is you have two networks. On the primary network you do most of your normal IP traffic between applications etc. Then you have a seperate marketdata network that has most of the multicast traffic and it's exclusively used for marketdata. Marketdata generally is delivered on an "As fast as possible" basis[2]. So you don't care too much about occasional…

I’ve seen some multicast market data protocols with remarkably poor ability to detect or recover from drops. And they are very much not of the form where a newer datagram supersedes the older one.

Yes, although people have been doing marketdata networks the way I said above using IP multicast for at least 20 years now, so in general they choose protocols and network architectures carefully to minimise problems. You do see problems from time to time but they are somewhat rare. Some of the restrictions are interesting. For example IP multicast was basically completely banned on the trading floor where I worked except for marketdata, because of an IP multicast snafu from some random application that took out the whole network once.

One thing to realise about marketdata specifically is it's really different from other low-latency situations most people are familiar with (netcode in a game for example). As I mentioned before, it's not that big a deal generally to miss a few packets - the thing that is a big deal is to make decisions based on stale data. So you're not generally trying to reconstruct the full state after a drop- you just want the freshest current packet as fast as possible. If/when you need to reconstruct state you can make specific requests if needed.

Post reply on HN