Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
1–10 of 143 posts
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#2Why not just switch to PTP (IEEE 1588)?
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#3An 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 segment of a virtual bit field, at speed.
So, now maybe we get a commodity 4096 bit 1 GHz CPU as a service. Which, is maybe comparable to a 64 core processor, but without the overhead of chunking down to the width of 64 bits.
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#4It 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, especially more and more cryptographic programs are being putting online, since this protocol is meant for financial applications, hopefully the security issues can also be solved by using digital signature.
I guess it's a rare scenario which the finance industry makes a _direct_ contribution to technology.
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#5This looks like a paper about the Huygens system, with comparison to other protocols like PTP: https://www.usenix.org/system/files/conference/nsdi18/nsdi18...
Also these slides: https://platformlab.stanford.edu/Seminar%20Talks/retreat-201...
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#6An 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?
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#7An 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?
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.
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#8It 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.
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#9Earlier 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…
Where's that useful? Options pricing? I have no idea.
Re: Google and Nasdaq Pursuing Nano-Second Precision in Network Time Protocol
#10Earlier 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…
Why would you use floating point math for finance?