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.
Thoughts on low latency trading if exchanges went full cloud
161–170 of 184 posts
Re: Thoughts on low latency trading if exchanges went full cloud
#162Earlier 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…
Re: Thoughts on low latency trading if exchanges went full cloud
#163The 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 would love some feedback!
Re: Thoughts on low latency trading if exchanges went full cloud
#164Earlier 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_.
Re: Thoughts on low latency trading if exchanges went full cloud
#165It'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.
*someone who is not a market maker
Re: Thoughts on low latency trading if exchanges went full cloud
#166Earlier 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.
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
#167The 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.
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
#168Why 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.
Re: Thoughts on low latency trading if exchanges went full cloud
#169Earlier 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…
Re: Thoughts on low latency trading if exchanges went full cloud
#170Earlier 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.
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.