161–170 of 223 posts
> its flagship Medallion Fund generate[d] average annual returns of 71.8 percent, before fees, from 1994 through mid-2014. Jeezus. That is about the same OOM as Moore's Law.
for comparison, according to one source, over 50 years, Berkshire Hathaway grew at about 21 - 22%
HFT / Fund guy here. This is marketing spiel. If you just want to trade on a bunch of exchanges so no information flows between them, you can easily (TM) write a program that either a) lines up the orders at each exchange to execute at a specific time or b) delays the orders from a central server by the line delay. So say NYC is 13ms from Chicago. You want to hit both at once. As long as you're not 13 ms late, nobody…
Say you send out $100mil orders broken down into 100 $1mil orders, they are going to take some time to execute completely.
Won't the HFT's detect them long before they are executed completely ?
Earlier quoted context omitted.
PTP - Precision Time Protocol. https://en.wikipedia.org/wiki/Precision_Time_Protocol . It requires hardware support, and a stable isolator inside of the machines.
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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.
A few weird things stand out to me: (1) Renaissance is super secretive. If they want to use this strategy to make money, a patent reveals to competitors what they're doing and creates more issues than it seems to resolve. (2) Renaissance is an HFT firm. Why are they interested in thwarting HFT? (3) This really isn't that fancy an idea. It's fairly general: send orders ahead to co-located servers to be executed at spe…
Think about it this way. They are publicly advertising to their investors that they have a weapon to defeat HFT. Because of this, they will get better returns. When an investor decides to put their money in a fund, are they going to choose the one that has a patented defense against HFT or will that investor put their money into a fund that has a known vulnerability? >It's fairly general: send orders ahead to co-loca…
"On a local area network, [PTP] achieves clock accuracy in the sub-microsecond range"
https://en.wikipedia.org/wiki/Precision_Time_Protocol
I disagree that the problem the patent purports to solve is particularly difficult, given the technology that is already readily available (PTP, an OS with a high resolution clock, machines located in exchange data centers).
HFT / Fund guy here. This is marketing spiel. If you just want to trade on a bunch of exchanges so no information flows between them, you can easily (TM) write a program that either a) lines up the orders at each exchange to execute at a specific time or b) delays the orders from a central server by the line delay. So say NYC is 13ms from Chicago. You want to hit both at once. As long as you're not 13 ms late, nobody…
I have a fundamental question. Say you send out $100mil orders broken down into 100 $1mil orders, they are going to take some time to execute completely. Won't the HFT's detect them long before they are executed completely ?
HFT / Fund guy here. This is marketing spiel. If you just want to trade on a bunch of exchanges so no information flows between them, you can easily (TM) write a program that either a) lines up the orders at each exchange to execute at a specific time or b) delays the orders from a central server by the line delay. So say NYC is 13ms from Chicago. You want to hit both at once. As long as you're not 13 ms late, nobody…
I have a fundamental question. Say you send out $100mil orders broken down into 100 $1mil orders, they are going to take some time to execute completely. Won't the HFT's detect them long before they are executed completely ?
What's described in the doc seems to be an algo for snapping up everything that's available across the various markets at one instant in time (rarely that much).
If you try to grab $100M when there isn't that much around, you'll have to wait until someone puts in more orders so you can trade with them. Any market maker (including human ones) will not let you trade again at the same price if someone's just taken out the whole market, so your next tranche will be executed at a worse price.
Dripping the orders into the market is very common, but of course you leak the information by doing it. For the HFT however it isn't as obvious as seeing that an order must trigger an order on another venue (NBBO requirements) and just rushing to pull your orders from there or trading ahead of that order.
HFT / Fund guy here. This is marketing spiel. If you just want to trade on a bunch of exchanges so no information flows between them, you can easily (TM) write a program that either a) lines up the orders at each exchange to execute at a specific time or b) delays the orders from a central server by the line delay. So say NYC is 13ms from Chicago. You want to hit both at once. As long as you're not 13 ms late, nobody…
the answer is 'we have loads of PhD math geniuses building the strategies and amazing execution technology'
that the institutional DD team is saying this to the investment committee or there is actually another entirely different reason?
HFT / Fund guy here. This is marketing spiel. If you just want to trade on a bunch of exchanges so no information flows between them, you can easily (TM) write a program that either a) lines up the orders at each exchange to execute at a specific time or b) delays the orders from a central server by the line delay. So say NYC is 13ms from Chicago. You want to hit both at once. As long as you're not 13 ms late, nobody…
I have a fundamental question. Say you send out $100mil orders broken down into 100 $1mil orders, they are going to take some time to execute completely. Won't the HFT's detect them long before they are executed completely ?
The point of this system is to send N orders to N exchanges in a simultaneous enough way that an HFT trader can't spot an order executing on exchange A and then issue their own order against exchange B.