Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol

This used to be true. Small HFT firms can find a niche thats profitable, but thats because there isnt enough money to be made by the big firms in those niches.

In the last few years there has been massive consolidation of the smaller HFT players, the space is commoditized and controlled by a few firms.

Of course the retail guy gets hurt. Who do you think buys the mutual funds that pay a higher price.

Seriously, I hear this all the time, but it’s only one step removed. Why does everybody keep repeating this lie?

"Also, no, small traders don't lose. Retail traders et al get much tighter spreads, cheaper execution by routing to internalizers, etc."

There's liquidity until there isn't. It was easier to get an order filled during a run to the exit pre-HFT. When everyone runs to the exit in an HFT world, retail investors are the last to get their orders filled, if they're lucky.

For 1), I'd randomize with proportional unit (share) representation, and I'd certainly be open to rule-prioritized execution (e.g. most-favorable taker first) if it didn't lead to degenerate incetives. Smart market design can incentivize people to play at their best price. For example: locational marginal pricing in wholesale energy markets...

2) I agree that the real world is quantized, but I think that a settlement tock to the bidding tick could be used to reduce the value of proximity. IEX actually implemented general latency with long runs of fiber, which is a really elegant fix. They couldn't make the rest of the world latent, so it's something like 700 microseconds, enough to remove colocation advantages, but only enough to solve for New York.

3) As far as I know, HFT's like to play in limit order and derivative books. It's where practices like flashing and spoofing have come from. Market orders are fraught with peril, especially if you don't know the matching rules for the exchange. As far as tightening the spread and aiding price discovery, I don't think that those two things are the same. If a security has naturally low volume, responsive high frequency trading can effectively be predatory.

4) I agree that there is more to HFT than just speed, but I view high frequency temporal arbitrage as an unnecessary market feature that provides the illusion of liquidity right up until that liquidity would truly be useful (since robots get benched when things go strange).

Granted, the temporal steps that I'm advocating here are a little provocative. The US could be solved in something like 200ms, and larger global markets, like currency exchange, are already fairly decentralized (though not as much as they used to be, as far as I know).

Either way, I don't think that NASDAQ can assure global temporal coherence, especially without controlling the entire network. Given that, it makes sense to design robust systems that don't pivot into rare modalities in exceptional cases. Just pull clock slew off the board.

I think you could account for hold-out by having the resolve window be longer than the trade-insert window, at least to an extent.

The trade-insert window can't be too long, or it would leave lots of room for regret, like people who voted by mail for a candidate caught in a scandal two days before an election.

why should randomization be clever? just fulfill orders in the book randomly for each time interval, wouldn't that be enough?

Not an expert so I might be totally off, but I think one of the risks is the existence of alternative markets.

Let's say you're only allowed to trade once a week, and I buy a bunch of Hooli stock at, say, $25 today. Then they launch Yet Another Hooli Chat tomorrow and everyone has decided that's going to make the price go up. You might want to buy some shares at $27 right now, because you think they'll be worth $30 next week. And maybe I want to see my profits right now for whatever reason (maybe I worry about them shutting down their new chat service by next week and I have a very low risk tolerance) and I'm happy to see some profit now instead of maybe more profit next week. Obviously I should sell to you. I can't do that via NASDAQ because we can't trade again until next week, but if you and I are in contact, we can just trade privately ("over the counter").

If lots of people start doing that, and we all join up, we essentially become another stock exchange. So it's not in NASDAQ's interest (or anyone's, really) for them to voluntarily stop doing things that will just cause another stock exchange to exist that does those same things. The options are either to convince market participants that the new rules are actually going to be better (more profitable) for them, or to lobby for regulation that makes the old rules impossible for someone else to implement.

As I understand it, this is basically the origin story of NASDAQ: the National Association of Securities Dealers believed (correctly) that they weren't getting good prices on existing stock exchanges, and computerizing a stock exchange had just become feasible, so they built an Automated Quotation system that initially just published prices to each other efficiently. Eventually it turned into an actual exchange.

I'd like to see qeternity chime in on this, since it's their space, but as market that is too rigid can't actually provide sufficient liquidity to users to function as an effective market.

Let's say you're comparing a savings account (1% interest, a day to withdraw), six month certificates of deposit (3% interest, six months out), and cash in your pocket (%0 interest, instant), and the goal is to account for market fluctuation in Laffy Taffy and come away with the most Laffy Taffy in a year.

The cash doesn't appreciate, but you can buy whenever the price changes. If Laffy Taffy is really volatile, working in cash gives you the flexibility you need to maximize your trade value and buy/sell at the right time.

If Laffy Taffy never sees a price change, put your money in that CD and wait it out (assuming no other available investment vehicles). You'll be able to buy a little more pancreatic strain in six months.

The savings account is somewhere in the middle.

A really large quantum for a market that attempts to serve as a proxy for real world fundamentals could be prohibitively risky for participants, and that could reduce overall market participation.

I suspect that there is a sweet spot, and I assert (without evidence) that the sweet spot is greater than the time it takes light to circle the globe.

Market makers have absolutely no incentive to quote tight spreads up until the last minute where they might have some idea about the price, or maybe not so they don't quote at all.

A lot of 'alternative solutions' to the continuous limit book assume that there's some other mechanism for price discovery so people make informed decisions, but really it is the book itself which provides that information.

None really. But having a tiny window privileges those who pay constant attention to the market. If the resolution was once a week all manner of riff raff could then invest and understand what they were doing.

> HFT companies managed to avoid using this exchange very successfully.

You mean they didn't accidentally trade on IEX? That's not surprising.

Also, I would believe that if you're doing pure latency arb, then trading on IEX isn't profitable, but there are other high-frequency strategies besides pure latency arb. Are you restricting your definition of HFT to pure latency arb strategies?

You would quantize the whole NMS, though that would still leave open tracking stocks and composites overseas and stuff.

I'm pretty sure you misunderstand market orders because by definition they are only visible to the market after they have traded, so nobody can get ahead of you or do sonething irrational before your order lands.

I would agree that market orders are a bad idea at any meaningful volume (outaide of retail sizes) because of liquidity and routing reasons

The other thing I don't understand is that this paper argues against hardware timestamping on the grounds that users won't want to buy expensive hardware, and that Huygens is for "standard hardware ... in current data centers". Expensive, niche hardware is normal for the HFT folks that care about nanosecond precision.

Haven't read the paper yet, but even it is data-center only, it is still very relevant for science, e.g. DAQ in nuclear physics, especially if it doesn't need custom hardware.

Oops.

The signal-to-noise ratio would be a nuisance, naturally, but there's a more fundamental problem that's stopped anyone from trying this. Internet routing and latency is asymmetric - your request to the time server will, in general, go via a different route that takes a different amount of time compared to the message back. This introduces a bias that is indistinguishable from local clock error. Without precisely synchronised clocks at both ends, you can only determine the overall round-trip time and not the time each leg took, and therefore you cannot calculate the exact difference between your local clock and the server. This is an inhererent limit on how accurate NTP can be over the Internet. (The other reason not to bother is that GPS is cheap and can provide a very accurate synchronized clock source over long distances.)

You usually have full hardware support, at least if you are using intel nics.

BTW, it's trivial to build a WWVB receiver nowadays, and a Rubidium standard only costs 200 USD.

You need to get the PPS to some other device, then it could be done. The whole GPS stratum 1 thing is mostly just PPS. You get the correct time with ntp, and the start of a second with the PPS from the GPS.

I'm not completely convinced that cheating would not be detectable after aggregating some statistics over time. (Similar to how you can extract encryption keys from server processes, simply by timing how long certain operations take.)

I don't think the article answers amelius's question, which is not about how you would achieve that precision but how you would use it. On an OS that only supports recording timestamps up to microsecond accuracy, what is the point of synchronizing your clocks within nanoseconds of each other, even if you could?

Actually, if you marshall all of your addressible units up front (4096 bit sentences, instead of 64 bit words), which aligns well with raw allocation units on many file systems, as an end user of the service, the overhead (to you) is reduced to network I/O if the product is built correctly.

The only hard part requiring serialized synchronization is the carry bit, across compute nodes. Share the carry bits between nodes, and while relaying a sentence to a cluster of synchronized nodes, the pipeline can shoot the sentence into the cluster as a unit, proxy and chain together the carry bits with a coordinated execution plan, and on the other side of the pipe, you get your well-timed 4096 bit result, all at 1 GHz, because the service is designed and produced to handle input at nanosecond intervals.

What are the advantages? Predictability, and expanded throughput.

Now you can look at an entire passage of text and make a determination about it in less time. Or stack many passages and composite them to assess or intuit variation. Designing the product this way makes it easy to reason about, and thus easier to market and sell. Is it possible to make a profitable system that works like this? Gee, great question! There's no obvious answer.

But anyway, from the perspective of a subscriber, it's on them to marshall their data, and then, if they have operations for which the scale of 4096 bit chunks improves results, they can get their granular operations done at 1 GHz, which allows them to predict time spent and overall cost more easily.

(e.g. I have all these [less-than-but-up-to] 4096 bit toots marshalled in a single data store, from a shit ton mastodon instances (i did all the crawling and retrieving, and saved them in one place, as a standardized data set), and I think this fact might be true about some of them, here is the rule set to interpret, please give me back the members of the toot array that return true when the function of this rule set returns true)

BTW, don't get hung up on 4096 as "the best number" I just chose it because it's a nice square number.

For financial transactions, it would certainly allow for fast high-precision floating point math. Imagine IEEE 754 4096-bit floats. Not sure anyone would actually use this, and you'd still have to standardize the rounding precision, but it might be an interesting vein of research.

Still, I agree with you -- what the OP described is not a 4096-bit processor.

Now highly-synchronized VMs -- that's an entirely different matter. Probably a boatload of use cases for those.

I don't know how you found your way onto the addition operator (+) on your keyboard, because that's not at all what I was driving at.

I think you are... JUMPING! TO CONCLUSIONS! (get it?)

Anyway, at it's core, much of the logic within a turing machine winds up being addition in an accumulator. So, you widen the pipeline, and that adds place settings to the numeric values addressed at a location in RAM.

I think we both know that each place setting increases the maximum valus of the addressible unit by an exponential factor of the base, which in computing, and so in this instance, is binary.

Specifically: 2^4096 instead of 2^64

Golly, did I get my math right? This sure is difficult to for me to understand!

Why would anyone want a 4096 bit CPU? Oh, I dunno. I suppose 640K ought to be enough for anyone.

I’m not quite sure what GP is getting at, either, but I can sort of see the lockstep synchronization described letting you build something like the original Thinking Machines Connection Machine out of more distributed parts.

The original Cray supercomputers also benefitted from a design where every wire in the pipeline was the same length for “free” synchronization courtesy of the speed of light.

An order of magnitude. Jeepers, that sounds really bad.

Economy of scale, my dude.

An organization seeking to market a product based on any spare slack or wastage of their bare metal could stitch together a niche product like this from enough resources, and price it in the space where it nets them money, and is cheaper than something an individual or small business might be capable of building on their own, with the cheapest possible parts.

That's basically the the core principle of every cloud product being sold.