Live data from Hacker News

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

nytimes.com

41–50 of 143 posts

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

#41
post #20

"So-called high frequency trading firms place trades in a fraction of a second, sometimes in a bet that they can move faster than bigger competitors." First off: no. Big money plays in high frequency trading (roughly half of all trading activity), and the smaller traders without instantaneous access are the losers in this game. Secondly, NASDAQ's obsession with precise global sequencing is A) misguided and B) effecti…

[deleted]

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

#42
post #20

"So-called high frequency trading firms place trades in a fraction of a second, sometimes in a bet that they can move faster than bigger competitors." First off: no. Big money plays in high frequency trading (roughly half of all trading activity), and the smaller traders without instantaneous access are the losers in this game. Secondly, NASDAQ's obsession with precise global sequencing is A) misguided and B) effecti…

> First off: no. Big money plays in high frequency trading (roughly half of all trading activity), and the smaller traders without instantaneous access are the losers in this game.

Vanguard is big money. Blackrock is big money. Fidelity is big money.

These big money vehicles are where most Americans, that have any investments at all, have their investments. So, honest question, should we care that smaller traders are the losers in this game?

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

#43
post #23
post #3

An interesting side-effect of this, is that it would enable a standard of synchronization, across geographic regions, such that one could treat a set of virtual machines as one ultra-wide-bus CPU with a 1 GHz clock speed. All of the local overhead of real system resouces and network synchronization could handled by the remainder of the real CPU clock available to the bare metal, but contribute to the computation of a…

"...across geographic regions, such that one could treat a set of virtual machines as one ultra-wide-bus CPU with a 1 GHz clock speed." I'm not entirely sure what you're trying to say here, but I am entirely sure that it's wrong. A precise clock isn't the same thing as the removal of latency, and the operations of a CPU are ordered. That is, I can't start working on the multiplication of A * (B + C) until the additio…

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.

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

#45
post #6
post #3

An interesting side-effect of this, is that it would enable a standard of synchronization, across geographic regions, such that one could treat a set of virtual machines as one ultra-wide-bus CPU with a 1 GHz clock speed. All of the local overhead of real system resouces and network synchronization could handled by the remainder of the real CPU clock available to the bare metal, but contribute to the computation of a…

Are you saying that 64 bit CPU + 64 bit CPU = 128 bit CPU (as long as they are time synced)? 1. It doesn't work this way 2. Why would you want a 4096 bit CPU?

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.

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

#47
post #6

Earlier quoted context omitted.

Are you saying that 64 bit CPU + 64 bit CPU = 128 bit CPU (as long as they are time synced)? 1. It doesn't work this way 2. Why would you want a 4096 bit CPU?

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

Good job, guys! Nice downvotes! Real nice!

I answered substantively, addressing each point carefully, and I was pleasantly rewarded for the time I took to respond.

Great incentive system you guys have worked out! Glad to see it being used as intended! Works like a charm!

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

#48
post #20

"So-called high frequency trading firms place trades in a fraction of a second, sometimes in a bet that they can move faster than bigger competitors." First off: no. Big money plays in high frequency trading (roughly half of all trading activity), and the smaller traders without instantaneous access are the losers in this game. Secondly, NASDAQ's obsession with precise global sequencing is A) misguided and B) effecti…

What would be the negative effect if the time quantum was much larger, say, an hour, a day, a week?

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.

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

#49
HFT aside, this also has interesting applications in distributed databases. Spanner, for instance, has consistency guarantees directly related to how synchronized the clocks are (keyword: TrueTime). It seems plausible that Huygens could make a significant improvement on performance of this kind of distributed database.

This looks like a very impressive result. NTP has been doing its thing well for years but a factor of 100 improvement on time accuracy would be amazing,

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

#50
post #18

How would you use that nano-second precision on a CPU/OS that supports at most microsecond precision?

Only if the article mentioned it! Oh wait, it did! https://www.usenix.org/conference/nsdi18/presentation/geng

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?
Post reply on HN