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

81–90 of 143 posts

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

#81

Post by makomk »

simias wrote: post #15
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…

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.)

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

#83

Post by danbruc »

tonysdg wrote: post #73
danbruc wrote: post #13

Earlier quoted context omitted.

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.

I'm aware of the fact that you don't use floating point math for finance -- for exactly the reason you described -- but the academic in me wonders if you could formally specify a high-enough degree of precision -- and all the corner cases -- to allow FP math for even just a subset of transactions. This would (in theory) allow to programmers to bypass the Decimal classes in your favorite OO language (or GMP if you're…

My point was more that it is wrong to say that financial calculations should not be done using floating point formats, for example Decimal in .NET and BigDecimal in Java are floating point formats and they are the types you should use for financial calculations. The important difference as compared to formats like IEEE 754 binary32 (formerly single) and binary64 (formerly double) is that the representation is based on base 10 instead of base 2. Fixed point or floating point and base 2 or base 10 are two orthogonal choices.

So when you initially mentioned high precision floating point numbers for financial calculations that was not necessarily a bad idea because you might have thought about base 10 floating point numbers. The comment I replied to however assumed you meant base 2 which of course most people do if they say floating point numbers without specifying the base and which of course is a bad idea for financial calculations more often than not. I just pointed out that assuming base 2 is usually but not technically correct.

And you can of course use base 2 floating point numbers for financial calculations - 32 bit, 64 bit, or 4096 bit - you just have to keep track of the accumulated errors and stop or correct the result before the error grows into the digits you are interested in. But why would one want to do this? The only thing I can really think of is that you need maximum performance and there is no hardware support for base 10 floating point numbers. And just using integers as base 10 fixed point numbers, which would often be a even better solution, must not be an option.

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

#84

Post by WellOver9000 »

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?

The alpha calculation can (and should) use floating point math. If the market has a midpoint of $99.99 with a bid/ask of $99.98/$100.00, you could compute a bunch of signals and end up with an alpha-adjusted midpoint of $100.00383736383..., at which point you’d convert it back to fixed-point and then try to buy $100.00

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

#85

Post by physguy1123 »

qeternity wrote: post #75
physguy1123 wrote: post #65

Earlier quoted context omitted.

Manning rule dictates that retail orders held by a market maker must be filled before any other orders (or equally that fills must be given to the retail order), brokers don't look kindly on firms that reject customer orders with any regularity, and anyways retail flow on a volatile+wide spread symbol are loved by market makers.

This. Even in markets with last look, you will lose your flow if you dick about too much.

I know of certain firms that will never reject retail orders unless they're truly invalid and will just fill at a loss to keep their flow.

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

#86

Post by zeth___ »

geofft wrote: post #48
myself248 wrote: post #26

Earlier quoted context omitted.

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

How is that different to the current alternative dark pools?

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

#87

Post by zeth___ »

myself248 wrote: post #26
chaboud wrote: 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?

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.

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

#88

Post by mrchicity »

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

Interesting idea, but how would you deal with these issues:

1.) Randomizing who receives contentious trades will just encourage order splitting and gaming. Sure some of that can be banned, but nothing stops big firms from putting each trading group into different legal entities or other tricks.

This also discourages traders from bidding their true most aggressive price. In time priority, you must, or someone else will snatch your trade. If you remove the reward, why take the risk?

2.) Being fast would still matter. Reality isn't quantized, so having access to relevant real world information or a proxy for such (trading activity in other markets or products) would still be an edge. Existing quantized trading points such as exchange auctions are still latency sensitive.

3.) The modern marketplace is interconnected. No ETF market maker will quote a tight spread if he can't confidently hedge his risk in the individual stocks. Going into a one second auction with random allocation is a lot riskier than just hitting the bid on Nasdaq, maybe paying an extra penny in the rare case when you're slow. A lot of liquidity comes from people running these arb/stat arb trades. It tightens spreads and helps keep prices in line. Why harm it?

4.) There is more to HFT success than speed and I don't think this would hurt them too much or take us back to 1997 with day traders sitting at home making big money. Virtu or some other HFT shop was the biggest trader on IEX, and they have a speed bump similar to this, just less extreme.

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

#89

Post by chaboud »

downer68 wrote: post #43
chaboud wrote: post #23

Earlier quoted context omitted.

"...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 nod…

"The only hard part requiring serialized synchronization is the carry bit, across compute nodes."

I don't think that's the only hard part. Branches, for instance, are rough.

"What are the advantages? Predictability, and expanded throughput."

I think the system you've described would definitely have some predictability, but I contend that it would be predictably slow. Furthermore, given that everything is going to have to be pipelined up to its eyeballs, you don't need nanosecond synchronization to achieve high throughout. Audio, for instance, often achieves higher throughout than clock. Look at the AES MADI spec for an example of this (basic link at Wikipedia here: https://en.m.wikipedia.org/wiki/MADI ).

I'm just not seeing how this is practicable, or, more critically for this conversation, how it is particularly uncorked by precision clocking in a particularly meaningful way. It strikes me as an approach that would have to deal with edge cases robustly, largely using the same mechanisms that would be necessary for imprecise clocking (but with assured sequencing).

"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."

This strikes me as similar to the complexity sizing in Craig Gentry's fully homomorphic encryption system, in that all operation sets up to a configured encodable complexity require the same computstional effort, effectively inefficient for smaller operations. For timing attacks in cryptosystems, it actually seems reasonable to retain fixed effort, even if Gentry's original system was largely impractical.

For general computation? I think that the sweet spot between job chunking and dataset chunking for the system you've described may not actually exist.

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

#90

Post by chaboud »

18pfsmt wrote: post #67
chaboud wrote: post #35

Earlier quoted context omitted.

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

Capital gains taxes are the same if you hold for a minute vs a month, but that doesn’t have to be true. I wonder if addressing the issue raised by the OP might be approached from that angle?

Continuously figured capital gains tax is a really interesting idea.
Post reply on HN