I wish the article had stuck with the technical topic at hand and left out the embellishment. In particular the opening piece talking about what is happening outside the exchange. What happens outside the exchange really doesn’t matter. The ordering will not happen until it hits the exchange. And that is why algorithmic traders want their algos in a closet as close to the exchange both physically and also in terms of…
How exchanges turn order books into distributed logs
41–50 of 73 posts
Re: How exchanges turn order books into distributed logs
#42Earlier quoted context omitted.
Interesting comment, I "felt" the ai too in an undescribable way. What are some obvious tells ?
The incessant bullet lists and the conclusion titled "Conclusion" give it away. And above all, the complete lack of "voice". You can tell when a human is speaking and when a sanitised amorphous blob of averageness is speaking.
> The log is the truth; the order book is just a real-time projection of this sequence.
> The book is fast; the log is truth.
> Matching engines can crash; the log cannot.
Re: How exchanges turn order books into distributed logs
#43Earlier quoted context omitted.
From the wiki about IEX: "It was founded in 2012 in order to mitigate the effects of high-frequency trading." I can see how they don't want to track internal latency as part of that, or at least not share those numbers with outsiders. That just encourages high frequency traders again.
One would hope for a more technical solution to HFT than willful ignorance lol. For example, they could batch up orders every second and randomize them.
Or leave things in place, but put a 1 minute transaction freeze during binary events, and fill the order book during that time with no regard for when an order was placed, just random allocation of order fills coming out of the 1 minute pause.
These funds would lose their shit if they had to go back to knowledge being the only edge rather than speed and knowledge.
Re: How exchanges turn order books into distributed logs
#44This article both undersells and oversells the technical challenge exchanges solve. First, it is of course possible to apply horizontal scaling through sharding. My order on Tesla doesn't affect your order on Apple, so it's possible to run each product on its own matching engine, its own set of gateways, etc. Most exchanges don't go this far: they might have one cluster for stocks starting A-E, etc. So they don't eve…
> My order on Tesla doesn't affect your order on Apple not necessarily many exchanges allow orders into one instrument to match on another (very, very common on derivatives exchanges)
Re: How exchanges turn order books into distributed logs
#45Earlier quoted context omitted.
I've been wondering if the stock market would be more efficient if trades executed only every instead of continuously, i.e. every 1 second an opening trade style cross book clearance happens. Orders would have to be on the book for a full interval to execute to prevent last millisecond rushes at the end of an interval I'm probably missing some second order effects but it feels like this would mitigate the need for ra…
You could do this but the cost would be wider bid/ask spreads for all market participants. If you make it harder for market makers to hedge their position, they will collect a larger spread to account for that. A whole lot of liquidity can disappear in a second when news hits. I’d rather have penny-wide spreads on SPY than restrict trading speed for HFTs. Providing liquidity is beneficial to everyone, even if insane…
The bad part of HFT is paying the smartest young minds this country has to offer to figure out how the parse GDP data as fast as computationally possible so they can send in an order before other players can. That's a dumb game that doesn't provide much benefit (besides speed in sparse critical moments adding a few % to the funds ROI).
They can arbitrage all day, but don't let them buy every Taylor Swift concert ticket the moment it goes on sale because they have a co-located office with a direct fiber line, ASIC filled servers, and API access.
Re: How exchanges turn order books into distributed logs
#46Earlier quoted context omitted.
The incessant bullet lists and the conclusion titled "Conclusion" give it away. And above all, the complete lack of "voice". You can tell when a human is speaking and when a sanitised amorphous blob of averageness is speaking.
Also three uses of a semi-colon for no reason. Nobody writes like this. > The log is the truth; the order book is just a real-time projection of this sequence. > The book is fast; the log is truth. > Matching engines can crash; the log cannot.
Re: How exchanges turn order books into distributed logs
#47Earlier quoted context omitted.
I was what was called "Trade Desk". Many firms have them and they are a hybrid of: - DevOps (e.g. we help, or own, deployments to production) - SRE (e.g. we own the dashboards that monitored trading and would manage outages etc) - Trading Operations (e.g. we would work with exchanges to set up connections, cancel orders etc) My background is: - CompSci/Economics BA - MBA - ~20 years of basically doing the above roles…
May I know if someone with no trading knowledge can get into this field? Or do new hires that you've seen generally have some background knowledge on related to trading, etc.? I did consider applying for a role in a very similar field, but figured I'll be fighting an uphill battle with no knowledge in trading/stock market/etc.
but that story is not the most efficient way (although I do talk about a better approach at the end).
To summarize:
A LOT of hedge funds hire non finance people for specific roles e.g. cloud, Linux tuning, networking etc
The smarter ones have realized that there are great people everywhere e.g. Gaming company SREs have a lot of relevant experience due to high traffic load, short SLAs and lots of financial risk due to outages. Applying for a role in one of those departments is a lot easier than trying to jump directly into a trading desk/operations role.
Finally, knowing someone on the inside also helps a lot which is made MUCH easier by LinkedIn, Twitter etc
Re: How exchanges turn order books into distributed logs
#48At a past job (hedge fund), my role was to co-ordinate investigations into why latency may have changed when sending orders. A couple of quants had built a random forest regression model that could take inputs like time of day, exchange, order volume etc and spit out an interval of what latency had historically been in that range. If the latency moved outside that range, an alert would fire and then I would co-ordina…
> they once swapped out a cable that was a few feet longer than the older cable and that's why the latency increased That was not why. Possibly the cable made a difference (had an open circuit that made the NICs back down to a lower speed; noisy leading to retransmissions) but it wasn't the length per se.
Re: How exchanges turn order books into distributed logs
#49Of the many thing trading platforms are attempting to do, the two most relevant here are the overall latency and more importantly where serialization occurs on the system.
Latency itself is only relevant as it applies to the “uncertainty” period where capital is tied up before the result of the instruction is acknowledged. Firms can only have so much capital risk, and so these moments end up being little dead periods. So long as the latency is reasonably deterministic though it’s mostly inconsequential if a platform takes 25us or 25ms to return an order acknowledgement (this is slightly more relevant in environments where there are potentially multiple venues to trade a product on, but in terms of global financial systems these environments are exceptions and not the norm). Latency is really only important when factored alongside some metric indicating a failure of business logic (failures to execute on aggressive orders or failures to cancel in time are two typical metrics)
The most important to many participants is where serialization occurs on the trading venue (what the initial portion of this blog is about; determining who was “first”). Usually this is to the tune of 1-2ns (in some cases lower). There are diminishing returns however to making this absolute in physical terms. A small handful of venues have attempted to address serialization at the very edge of their systems, but the net result is just a change in how firms that are extremely sensitive to being first apply technical expertise to the problem.
Most “good” venues permit an amount of slop in their systems (usually to the tune of 5-10% of the overall latency) which reduces the benefits of playing the sorts of ridiculous games to be “first”. There ends up being a hard limit to the economic benefit of throwing man hours and infrastructure at the problem.
Re: How exchanges turn order books into distributed logs
#50GPS can provide fairly accurate timestamps. There's a few other GLONASS systems as well for extra reliability.