Thoughts on low latency trading if exchanges went full cloud • Hacker News Board

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

#111

Post by dchftcs » Tue, Apr 16, 2024, 4:02 PM UTC

pas wrote: post #88

smabie wrote: post #75

Earlier quoted context omitted.

Or we could just.. not do that? It provides no benefit and a host of downsides

It seems a lot more elegant/efficient/sane to me than trying to squeeze more and more racks into one building. So that's why I'm asking, as I think the benefits are clear, much better scalability, fairness (or getting as close to it as the exchange wants), cheaper (no need for fancy hardware), probably it would attract more market participants (lower barriers to entry). It's the same hypothetical "EC2 model" without…

What you're trying to eliminate is just a small part of the infra arms race. But it's not even effective at that. You say one of the goals is to not have to squeeze many racks into a building, but your proposal assumes the servers placed in the racks are running at low capacity, which is completely not true. On the other hand, if you trade say GOOG, the matching engine for that is going to mainly sit in one place, how do you stuff everyone's program to run on the same server, and how do you make sure they each have fair access?

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

#112

Post by kristjansson » Tue, Apr 16, 2024, 4:08 PM UTC

I like the assumption that NYSE would just grab some EC2 instances and run an exchange on them, and that AMZN wouldn't bend several directions at once to deliver new products that just happen to exactly replicate the environment they're 'leaving'.

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

#113

Post by moomin » Tue, Apr 16, 2024, 4:12 PM UTC

The author of this article clearly knows a lot about the subject, but I think this would have been better titled "Low Latency Trading isn't Going To The Cloud and Here's Why". Or to put it a different way, infra peeps within exchanges have a very specialized skill set and priorities. General cloud infra peeps don't. No shade, but there's always going to be some business that doesn't make sense to switch to the standardized solution.

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

#114

Post by georgelyon » Tue, Apr 16, 2024, 4:25 PM UTC

posnet wrote: 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 ran into this problem a while back working at a company that was working to distribute video streams with low latency (lower than Low-Latency HLS) to a large number of viewers. Initially a prototype was built on top of AWS with fan-out/copying and it was terrible. This was partially due to inefficiency, but also due to each link being a reliable stream, meaning dropped packets were re-broadcast even though that isn't really useful to live video.

Moving to our own multicast hardware not only greatly improved performance, but also greatly simplified the design of the system. We required specialized expertise, but the overall project was reasonably straightforward. The biggest issue was that now we had a really efficient packet-machine-gun which we could accidentally point at ourselves, or worse, can be pointed at a target by a malicious attacker.

This 1-N behavior of multicast is both a benefit and a significant risk. I really think there is opportunity for cloud providers to step in and provide a packaged solution which mitigates the downsides (i.e. makes it very difficult to misconfigure where the packet-machine-gun is pointing). My guess is that this hasn't happened yet because there aren't enough use-cases for this to be a priority (the aforementioned video use case might be better served by a more specialized offering), but exchanges could be a really interesting market for such a product.

It would be pretty efficient to multi-cast market state in an unreliable way, and have a fallback mechanism to "fill in" gaps where packets are dropped that is out-of-band (and potentially distributed, i.e. asking your neighbors if they got that packet)

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

#115

Post by munk-a » Tue, Apr 16, 2024, 4:28 PM UTC

Low latency/rapid trading seems to have added no value to the stock market and eroded a large portion of the fair market evaluation of companies. Whether it's technically possible or not it's likely we'll need to artificially add delay into the system - ideally that can be done in a way that makes it fair to traders that have a naturally high latency connection to even the playing field.

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

#116

Post by maerF0x0 » Tue, Apr 16, 2024, 4:29 PM UTC

munk-a wrote: post #115

Low latency/rapid trading seems to have added no value to the stock market and eroded a large portion of the fair market evaluation of companies. Whether it's technically possible or not it's likely we'll need to artificially add delay into the system - ideally that can be done in a way that makes it fair to traders that have a naturally high latency connection to even the playing field.

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.

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

#117

Post by renewiltord » Tue, Apr 16, 2024, 4:32 PM UTC

xnorswap wrote: post #92

WiSaGaN wrote: post #82

Earlier quoted context omitted.

> You could match what you can distributed equally and leave the rest unsettled. Equally per market participant? Do large participant like banks trade same amount as retail investor one trade at a time? Per quantity? HFT will time the end of the interval and decide to place a large order or not.

It would be weighted by bid size. If there's $10m of bids one side and $5m of offers on the other, you match up the $5m on that side and every bid gets 50% settled. I'm not sure I understand the problem with "waiting" for the end of the clock. The pool wouldn't be public so you couldn't get knowledge inspecting the pool. All bids and offers would be published on the clock and settled by weighing all the bids and offe…

This is all gameable. Like he said, you just time it with an over-large order and let the remainder expire. Everyone gets 10% of their order but my order is 10x what I actually want so I actually get 100%.

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

#118

Post by lucianbr » Tue, Apr 16, 2024, 4:34 PM UTC

Kranar wrote: post #109

lucianbr wrote: post #71

Earlier quoted context omitted.

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.

What do you think an Average Joe is going to do with that extra millisecond available to them?

I think Average Joe has quite a lot of disadvantages compared to some hedge fund or whatever it is that does HFT. Do you really think the only difference between them is a millisecond? That's only between HFT traders.

My point was that other advantages/disadvantages are not being cared about, not that we should provide milisecond access to Average Joe.

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

#119

Post by sour-taste » Tue, Apr 16, 2024, 4:43 PM UTC

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 should be, or a single hard drive storing important data crashes? Lots of interesting failure modes. When the NYSE owns their own machines they can handle these cases directly. When they don't and Amazon is responsible for repairing these machines it might take a lot longer to get things fixed. I hope NYSE is thinking about hardware failures and building a system to check performance of their trading servers before letting them become the active host.

Thinking about failures on the side of the traders: basically if they get unlucky then there could be delays as Amazon rerprovisions them replacement servers in the case of failures. This likely impacts what trading strategies are viable, and could cause them to lose money if machines fail at unlucky times.

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

#120

Post by HALtheWise » Tue, Apr 16, 2024, 4:43 PM UTC

amluto wrote: post #85

posnet wrote: 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…

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

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 way that would allow some output ports to get slowed down.

If there are other data flows also going through the switch, that could obviously change things, and the sending computer could drop packets if there's jitter in how quickly the application produces them, but it seems impossible for the sending computer to burst packets into the switch any faster than it can handle because all the incoming packets are coming over the same 10G link.

Not an expert here, legitimately curious.