Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nytimes.com

Post reply on HN
Print view View original

11–20 of 143 posts

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

#11

Post by ComputerGuru »

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

I don’t think you understand how memory bus width is calcuslated or what it means. You are an order of magnitude off on the layer in question.

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

#12

Post by danbruc »

tonysdg wrote: post #7
dagenix wrote: 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?

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…

64 bits already gives you 16 digits, that is enough for a trillion dollar to one one-hundredth of a cent. So maybe there is someone who needs 128 bits, which is part of IEEE 754 since 2008, but that then is probably enough to calculate the total of all financial transaction ever done.

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

#13

Post by danbruc »

fjsolwmv wrote: post #10
tonysdg wrote: post #7

Earlier quoted context omitted.

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…

Why would you use floating point math for finance?

A floating point representation is not really the issue, the issue is not using base 10, and IEEE 754 specifies base 2 and base 10 floating point formats and operations. But I am of course not sure whether the original comment referred to base 2 or base 10 and given how common the mistake of using base 2 floating point numbers for financial calculations is, you may be correct with the intention of your comment.

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

#14

Post by bcaa7f3a8bbc »

makomk wrote: post #8
bcaa7f3a8bbc wrote: post #4

It is great news if this algorithm can work directly on the public Internet, without requiring a specialized network - many scientific and engineering applications will be able to get its time reference directly from the Internet! NTP and other protocols currently used are unauthenticated (there is NTP autokey, etc, but its security properties are not ideal, and mostly not deployed) and it is a big security hole, esp…

If I'm understanding the Huygens paper linked in one of the other comments correctly, this is strictly in-datacenter only; it relies on properties of datacenter networking that don't apply to the broader internet, in particular that routes are mostly symmetric and mostly low-latency.

Oops.

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

#15

Post by simias »

bcaa7f3a8bbc wrote: post #4

It is great news if this algorithm can work directly on the public Internet, without requiring a specialized network - many scientific and engineering applications will be able to get its time reference directly from the Internet! NTP and other protocols currently used are unauthenticated (there is NTP autokey, etc, but its security properties are not ideal, and mostly not deployed) and it is a big security hole, esp…

I can't imagine how you could hope to reach nanosecond-precision over the internet without changing all the routing hardware in use today. With PTP you can already reach sub-microsecond synchronization but you need full hardware support for every network element on the route if you want to achieve that. The timestamping is done on the network PHY itself, which is how you can remove all jitter introduced by the kernel stack. Anything receiving and re-transmitting the packet along the way must update the timestamps to account for the processing delay.

Huygens is a little more clever and uses a statistical approach to sample multiple clocks and correlate them (if I understand correctly) however it still seems designed to work within a datacenter, I assume that over the internet the signal-to-noise ratio for measurements would worsen very significantly and lower the precision dramatically. It could well still outperform NTP however.

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

#16

Post by Forge36 »

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

How would the math work on that? Simple addition now requires coordination of results across many CPUs. Worst case is N-1 ticks where N is the CPU count. What operation would get faster by such a virtual CPU?

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

#17

Post by simias »

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

Suppose you do a simple addition on your 4096bit "CPU", you have to propagate the carry from the first 64bits to the next 64. How do you do that within your clock cycle over the internet? You'd have to pipeline them so that each subsequent 64bit add waits for the previous carry, but then wouldn't it be orders of magnitude faster to just do it on the same CPU rather than taking the time and resources to do a single 64bit add followed by a high latency network transfer? At any rate what does clock synchronization buy you here exactly, data transfer are still high-latency and high-jitter, at best you're isochronous but definitely not synchronous.

Either I completely misunderstand what you're proposing or it doesn't make sense at all.

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

#19

Post by wmf »

bcaa7f3a8bbc wrote: post #4

It is great news if this algorithm can work directly on the public Internet, without requiring a specialized network - many scientific and engineering applications will be able to get its time reference directly from the Internet! NTP and other protocols currently used are unauthenticated (there is NTP autokey, etc, but its security properties are not ideal, and mostly not deployed) and it is a big security hole, esp…

It would probably be more accurate to install a stratum 1 NTP server on your phone since it has GPS. But then you'd probably get hit with jitter from Wi-Fi/Bluetooth/USB.

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

#20

Post by chaboud »

"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) effectively impossible to do right 100% of the time. Given this, I would argue that the appropriate thing to do is change the market requirements. And I'd argue that like this:

1) Temporally quantize the market. Orders come in on an open temporal window that is sufficiently long to account for global latency of non-pathological communication (sorry, tor users) and a bit of computation time. Everyone gets to swim in the same pool. Maybe one second, maybe more. Nobody gets to see the order book until it's resolved. Write-only. 2) Lock the book and fulfill orders from the set of satisfiable orders. If there just contention for a trade (there will always be some), fulfill the contentious trades randomly using random zeedig generated from a pre-announced salt and a hash of some or all of the order book for the window. 3) Return the results and the hashes of the order book, next salt, etc, for verifiability and prep. 4) Re-open the order window.

High frequency traders would hate this, because they wouldn't be able to pounce on quick movements, even without fronting slower traders.

It would, naturally, increase latency for trades by virtue of having to wait for market resolution. However, mere sequencing doesn't solve the problem of having to resolve and confirm trades (the speed of light is so cruel), so I'm left utterly unsold on the market-efficiency benefit of ultra-high order resolution. Wealthy high frequency traders want to use time to buy an advantage, and the liquidity support they provide to the markets is dubious, at best, since they pull the plug as soon as things get crazy.

Quantize the markets.

Post reply on HN