Hacker News new | ask | show | jobs
by bob1029 1704 days ago
There are severe technological consequences for pushing for synthetic discrete time. Exchanges that currently execute in a serialized fashion may no longer be able to support the trading volume if the underlying platform is unable to develop batch sizes that naturally align with hardware capabilities and timings.

Put differently, I think what is going to happen is you will start stacking way more orders at each interval than you can process before the next because the wonderful CPU pipelining effects get wrecked each time you hit an arbitrary time slice boundary. I suppose you could intentionally spin the CPU instead of yielding back to the OS during these delays, but that means you are not able to process any orders that are currently arriving, so your tail ends up growing longer and longer.

3 comments

I would be very worried if the machines actually executing orders today were anywhere close to 100% load on average, because of the well-known issue where tail latency explodes as you get closer to 100% load. So I doubt the relevance of everything you wrote there.

Batched auctions require different algorithms, sure. They may even be more expensive to execute. I suppose you have to sort the batch once instead of sorting as you go. Maybe that makes it O(n log n) instead of O(n)? Can you keep a traditional order book up-to-date in O(1) per transaction? Either way, seems like this should be a non-issue. Even if exchanges need to add more shards for order processing, that's just not a big deal.

This hasn’t materialised as a problem (batch auctions are one on the MiFID II venue models) - some eu venues have run this model for around four years now, its definitely less widely used than other models but has a niche.
It might not have materialised as a problem because those venues are not handling as much traffic as the busiest CLOBs are.
Why would a premade queue be worse for pipelining than a random queue which you also have to modify as you process on it? Seems like a single pause per batch rather than constantly checking if the work queue has something new put in it.