Hacker News new | past | comments | ask | show | jobs | submit login

Its invention, developed by the firm’s co-chief executive officers, Robert Mercer and Peter Brown, first sends an order to a central server, which breaks it up into multiple smaller orders. Those are then routed to venues that offer the best prices and most liquidity, much the same as brokers do now.

But before that happens, the smaller orders are sent to servers located as close to the exchanges as possible, along with instructions on the precise times they should be executed. The co-located servers sync their transactions so HFT firms won’t have enough time to identify an order on one exchange and then race to another to trade against it.

A crucial part of the system is the optical, atomic or GPS clocks that will be used synchronize those orders. Renaissance says in its application that GPS clocks are accurate to within nanoseconds and any time differences between them are “too small to be perceived” by HFT firms.

Maybe I'm missing something but sending orders ahead and releasing at a specific time is obvious is it not? If you add a really accurate clock suddenly it's patentable?




I don't know why you need a great clock either, if you have stable, symmetric network paths from a central location to all your servers colocated at exchanges, you can predict the delay between sending from the server and getting to the exchange, you can split your order and send it to the various exchanges with appropriate delays and know that everything will arrive at the same time. If you're wrong, it's going to still be close enough that nobody will be able to see it on one exchange and react to it on another before your order gets there.

This was the first thing I thought of when hearing the flash boys story on the radio: The banker was complaining he couldn't capture the whole book across exchanges because resting orders were cancelled before his order got there -- he just needs to get his orders to arrive close enough in time (although expect a bigger tick, probably)


That exact strategy is also mentioned in Flash Boys, in the form of THOR.

https://en.wikipedia.org/wiki/THOR_(trading_platform)


Keep in mind that Flash Boys is not worth the paper it's printed on.

(See https://www.goodreads.com/book/show/23570025-flash-boys)


In any argument there is your side, their side, and the truth.


And not all sides have an equal distance to the truth.


beautifully said

I've evolved to keep this rule in mind when I hear almost any story/portrayal/claim/news anymore. Especially anything that feels sensational or too-good-to-be-true-at-first.

For example, people often lie about sex or money. National governments often lie about, well, pretty much anything that suits their best interests. When I say "lie" I don't mean completely wrong or totally false, merely, spun a certain way, sometimes a careful omission of critical modifiers, the use of weasel words, etc.


Network delay variance over distances is much greater than the timescales at which HFTs function. That's why HFT equipment is always so close to the exchange itself.


But it's not significant in the domain this thread is focused on. In order to lose signal to an rival in this scenario, the delay between your Order A hitting Exchange A and your Order B hitting Exchange B would need to be sufficient to give the rival time to learn the signal, and then to act on it. At a minimum, that is half the cost of the round-trip time between the Exchange A colo and the Exchange B colo. So long as you're not introducing such substantial delays in your order dispatch, you're fine.


I havent read the patent but I can say this is an exceedingly common (I'd probably say standard) strategy. I can only assume the atomic clock bit is what's novel.


Using ntp or whatever the new variant is is also standard, which as I recall can hit sub-microsecond consistency on a wide area network with good hardware. So yeah, not new.


PTP - Precision Time Protocol. https://en.wikipedia.org/wiki/Precision_Time_Protocol. It requires hardware support, and a stable isolator inside of the machines.


It doesn't require hardware, though it really improves the performance. I've implemented 1588 a few times and was able to achieve ~ <30ns accuracies when using hardware timestamping. Also note that there are more and more MACs and PHYs these days that offer HW timestamping.

With software, it really depends on how deterministic your packet handling and timestamping routines are (or how deterministic the OS scheduler is). I was able to achieve accuracies of less than a microsecond on a Linux system, but it was "touchy".

For reference, there's an open source implementation called "ptpd" and "ptpd2".


Little know fact, you can use the GPS constellation to get atomic level precision time nearly anywhere on earth. Using an Atomic clock is purely to show off to investors/a red herring.


Exactly. GPS is by far an easier way of synchronizing clocks to an atomic reference compared to any master-slave networked approach, especially in situations where we're talking about a small number of stationary, expensive servers which are far apart.

PTP is mainly useful for situations where you want to synchronize many cheaper slave devices to a common master and it's not practical for each device to have its own GPS receiver, or for situations where the use of GPS isn't practical (or is prohibited) and you're more concerned about coherency between devices rather than traceability to a primary time reference (e.g. a telemetry network on an aircraft). Although, generally, the grand master of a PTP network is synchronized to GPS anyway.

Of course, you could achieve actual phase locked synchronization down to the clock cycle with something like SyncE + PTP, but with GPS, you need not worry about issues with asymmetry regarding messages transmitted over the internet (PTP needs to be routed through PTP capable switches which compensate for the residence time and was really meant for LANs).

I guess it really depends on your constraints, but if you’re able to use GPS, that would definitely be my first pick when it comes to synchronizing multiple devices.

The latest UBlox timing receiver (LEA-M8F) provides a PPS which is accurate to less than 20 nanoseconds (to the UTC second) and its built in oscillator has a typical holdover spec of 0.025 PPM (25 nanoseconds per second). If you want to get fancy, you can use the PPS to discipline an OCXO and get an even better holdover spec to handle the situations where your receiver may lose lock (which is unlikely if you’re able to have an antenna).

Basically, the accuracy of the UBlox GPS receivers (just an example since they're pretty cheap; I found a board for ~$150), is equal to or better than that of a usual PTP link (without SyncE), so you might as well just use GPS on each device if you can. It is simpler, IMO.

However, note that comparing GPS to PTP isn't necessarily valid since PTP is purely a method of conveying timing information between devices, and is not a time source itself, where as GPS is both a method of conveying timing information as well as a time source. In other words, a PTP network still needs a master device which itself is synchronized to (or is) an atomic clock.


I would've thought that GPS is too unreliable due to the deliberate inaccuracy? Only the US military have the clean signal.

Particularly if you're using it to sync between two different time zones that could well be looking at different satellites.

However, I don't know how much inaccuracy is introduced and whether it would have too much of an effect for the purposes of Google, et al.


Bill Clinton turned off the deliberate errors back in 2000:

http://www.nytimes.com/2000/06/15/technology/pentagon-lets-c...

The errors you see in your mobile phone's positioning are due to signal problems (reflections, etc) and the relatively limited capabilities of the cheap GPS radio in your phone. A decent GPS receiver with a well-positioned antenna will get a highly accurate clock.


That's been removed. But, just for fun.

Speed of light is 299,792,458 m/s. So if GPS is off by more than 1/10,000,000 you can't get accurate within 30 meters. Having used a GPS they are better than that, thus the clock must also be at least that accurate. Of note, stationary stations can get into centimeter precision which imply's vastly higher accuracy.


Fun fact. GPS is so precise that they can detect the fact from GR that gravity makes clocks run slower closer to the ground.


oscillator I think you mean? IEEE 1588 v2 is considerably better for financial applications.

Source: I work in finance as a techie.


Except that the state of art in HFT is sub-microseconds

"London-based trading technology company Fixnetix said Tuesday it has the world’s fastest trading application, a microchip that prepares a trade in 740 billionths of a second, or nanoseconds." (WSJ, 2011)

http://blogs.wsj.com/marketbeat/2011/06/14/wall-streets-need...

http://stackoverflow.com/questions/17256040/how-fast-is-stat...


Isn't the relevant delay rather that of a signal traveling from one exchange to another?


That's one of the factors. Generally the optimisations that happen first are on network path length / network equipment induced delays, as there's relatively cheap and quick gains to be made. The bigger delays are invariably in your applications that are processing or generating data, which are more costly to optimise.

That said, the Fixnetix stuff is only talking about one aspect of what's involved, and about as representative of reality as Cisco's published WARP speed figures in their Nexus 3500 range.


The atomic clock bit isn't novel at all. I've worked for HFT firms the past 9ish years and using hardware timesources is 101 level intro to electronic trading.


But atomic ones? We used ptp or gps for this sort of work but I don't know that I've seen an atomic clock.


The actual patent talks a lot about NIST GPS clocks, and not so much about atomic clocks. Never trust a headline. Gell Mann Amnesia Effect in full play here.


Sure. You can't get roof access (for a gps antenna) or a vendor ptp feed in every exchange. In those places, you get a rubidium decay stratum 0 timesource.

Not all businesses can afford this, but it is only 4 or 5x the price of a normal GPS timesource, which is affordable for the right people.


Apparently the claimant doesn't believe so. The atomic clock isn't mentioned in all the independent claims.


And with hft guarded so well, can't they just use the patent and not get caught?


The idea doesn't help the hft'ers. It takes an order, secretly transmits it to computers each as near to the major markets as possible, with instructions so that the computers submit the trade offer at precisely the same time.

The hft'ers can't make money since they can't outrun trade offers that are synchronous across all markets.


As someone with zero domain knowledge, why aren't the exchanges already doing precision timed order processing? That just seems like it's should be a standard feature across the board. The broker sends buy/sell orders with planned execution times to all the required exchanges and the exchanges sit on the orders until the designated time.


Exchanges do time ordered processing on their own exchange (with different levels of precision). I don't know of any exchanges that offer execution time as a constraint, but new order types can be created if they were deemed valuable (it takes SEC approval).

That said, it wouldn't alleviate the issue necessarily. If firms detect problems in the clock sync between exchanges you are right back to the same problem, and now you've added a complex bit of tech that requires a bunch of competitors to agree on.

This seems, to me at least, to be one of those problems that it is better to let the problem surface than to try to alleviate with an abstraction layer that is leaky and error prone.


But this technology is patent is just implementing the exact same thing at one layer removed from the exchange. You still have to time the orders and you still have to keep the timed orders confidential. To me, using a 3rd party to do this instead of having it as part of the base system is... silly I guess.


As someone with zero domain knowledge, why aren't the exchanges already doing precision timed order processing?

HF traders give the exchanges a nice cut (colocation costs, etc). Not many corps can afford it.


What? It generally only costs a few thousand dollars per month to colocate servers next to exchanges.

Arguably, it is more fair now than it ever was in legacy "open outcry" markets where the size of the floor was fixed and if you didn't get a spot on it you weren't able to compete.

Disclaimer: I've worked in HFT 9ish years (10 soon)


All they're saying is that with absolute synchronicity among all of the clocks at all of their co-located servers, all pieces of the order are executed at multiple exchanges at precisely the same time. Even very small differences among the clocks at each one can create opportunity for others to step in front of the trade, and this helps them avoid that. While this may sound obvious, they wouldn't be doing it if it hadn't been a problem for them in the past.


Nanosecond differences are too small to take advantage of, that's only 30cm. My guess is that you'd be at least in (or close to) the microsecond range before you'd worry about HFT stepping in front of your orders.

If you're hitting multiple exchanges, then you can take milliseconds and still be fine.


One of the things HFT firms take advantage of is increasing a nanosecond lead into a microsecond (or more) lead by route optimization. If they can get information from one exchange to another faster than the original order, they can effectively trade by looking into the future.

Many firms invest heavily in direct microwave links for paths normally served by fiber because of the speed advantage.


Those microwave routes operate at tens of millisecond advantages over the competing fiber routes.

[edit] Completely wrong comment. The microwave link I was thinking of had a 2 milli advantage over the fiber link.


Speaking from ignorance here but 10s of milliseconds sounds way too high.

This Wikipedia article [1] shows the standard Chicago to NJ connection at 14.5ms roundtrip and the dark fiber line Michael Lewis talks about in Flash Boys at 13ms.

[1]: https://en.wikipedia.org/wiki/Spread_Networks


You're right. The microwave link was ~2 millis faster. Just misremembered. Sorry.


Which is irrelevant here because there is a timed relay server at each exchange.


Microseconds are not enough, because the arbitrage works by the HFT setting the order in one place, and then rushing the arbitrage to the other place. As long as you're more coordinated than speed of light between the two locations, you're fine.

Also, GPS clocks are cheap and precise, atomic clocks seem gold plating. (Which sometimes is actually necessary in electronics, BTW...)


GPS can fail. Atomic clocks give you a second system to fall back on.

At Google, we use both GPS and atomic clocks for Spanner.


I think the main innovation in Spanner is the notion of Truetime not the atomic/gps clocks though. In fact MSR has come up with something called ClockSI that does global snapshots with a modified NTP I believe.


Yes, I think you are right.


Hardware (e.g. FPGA) autotraders can have sub-microsecond response times.


Unfortunately for the traders, two of the clocks were at altitude and so time passed more slowly for them, resulting in several femptoseconds of misalignment :-)


You joke, but Google actually uses GPS mounted on the roofs of their data centers for time synchronization.


GPS plus atomic clocks.

And, boy, do the off-the-shelf commercial offerings suck. The vendors are not really used to dealing with the stress that Google puts these things under.


Could you elaborate on that?


Sorry, not sure I am allowed. :(

But, their drivers and APIs seem woeful judging by the complaints I heard.


And let me guess, you built your own rubidium decay device, as most do :)


I agree. Atomic clocks are an implementation detail, and also overkill (at least during this decade). I've worked in HFT (albeit in forex, not stocks), and there are always internal delays within the exchange that you cannot predict with anywhere near the accuracy of an atomic clock. (Well, if you could, then that would be a true innovation.)

Hedge Funds don't patent strategies. They keep them as trade secrets. It would make more sense to me if this filing was part of an attempt to build a patent portfolio for defensive purposes, as tech companies do.


The way many patents are structured begins with "a method of..."

So, in that sense, "a method of coordinating orders across exchanges to minimize analysis time available to other traders" seems perfectly in line.

(I agree that from various computing-centric backgrounds, this might be trivial, but not all problem domains are well-saturated with computing expertise, and this might well be sufficiently novel to warrant a patent in the domain.)


Novelty and obviousness are more related to whether something has been patented already or not.


> The co-located servers sync their transactions so HFT firms won’t have enough time to identify an order on one exchange and then race to another to trade against it.

That sort of sounds like DDOS to me. They patented a DDOS botnet.


No its not at all like that. Its a synchronization strategy so that orders hit all exchanges at the same time.


I assume the traders can't place orders with time of execution (to be executed at the specified time, kept secret until then).

If the market accepted the time of execution from traders and kept the trades secret until they were executed, then there would be no need for these patents.


There may be some exchanges that accept some sort of specialized order type that allows for time of execution as a constraint. That said, this issue is about synchronizing between exchanges and there certainly aren't any exchanges that collaborate to do that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: