Which, at the same time, is pretty irrelevant if you save 5ms there.... and it takes 50ms to get the order from your offsite hoster to RIthmic. As example: I currently trade CME etc. I get data from Nanex / Nxcore. My servers are in Nürnberg, germany. Ping time 117ms to NxCore. The faster broker shaving off 5ms on their executing platform wuold make NO real difference - movign my servers for trading close to the exchange and data feed (10ms) would make a lot more. Just meant as example. Moving to a close data centeri s the biggest impact. THEN, once you are there, only do ge broker speeds etc. relevant. In my style "faster than visual" is good enough at the moment. Again, not talking down Rithmic - they do a terrific job, seriously. But one needs to be aware where the real bottlenecks are first. In my case, pretty much every hosting center in the US would shave off 60% of the time. Most would cut off 100ms.
NetTecture Hope you are doing well. I've been away for a while and it's good to see you are still speaking sense on these boards. If I remember correctly you go through Vision's Rithmic infrastructure? Seriously, get some managed boxes in downtown ChiTown. Won't cost you any extra I'd imagine and you'll shave off that epic transatlantic dead time. BTW, Vision are talking about doing some sensibly priced colo options for their Rithmic customers. That would definitely be worth investigating.
My basic recipe is first find a profitable strategy and, then might perhaps begin to think if your latency really might represent a problem. I am trading from overseas and frankly I don't see how a 100 ms latency could ever represent a problem with any sensible strategy. Further, if really latencies of this order of magnitude are a problem, your strategy may be potentially subject to drawdowns which can be unbearable by most investors or hedge funds. Tom
Tom, In a liquidity squeeze 100ms is an eternity which can affect entry/exit prices by several ticks. When it can be shaved off by colocating your boxes close to your brokers infrastructure I fail to understand why anyone wouldn't want to do it.
Hmmm, taking "several" as >= 2. That would be >= 20 ticks per seconds. I am following market realtime and i am not seeing that. For instance, for futures contract ZB, it would be a variation worth >= 625$ per second. And even if i saw that, i frankly don't believe in strategies which attempt to take advantage of such occurrence. Could you describe a strategy profitable working with that timeframe ? T
The 30 year bonds is typically a slow market with deep liquidity. Try trading crude or the euro and you will often see liquidity dry up immediately prior the initiation of a move. Large professional interests will spot this and cross the spread in a scamble for the remaining liquidity. If you want to get in on this action you need to be fast. Fractions of a second really count and determine whether your marketable order gets executed at the inside market or several ticks away. Given that you can colo for a relatively low cost these days, why wouldn't you want to give your strategy to best shot possible of reacting to rapid situations? Low latency doesn't have to be the basis for your strategy for it to make commerical sense.
Because it's not worth, in my humble opinion. You would pay a fixed amount for something not necessary, and, what is worse, even "conceptually" misleading. Further, trading actively such timeframes, the drawdown can be, potentially, unbearable for any investor (or one needs to trade very rarely, waiting for "special occurrences", with no guarantee of success, clearly, as when you see a condition that's already past.) Well that's just my opinion, I am not saying that you are wrong and I am right. Just a different view ;-) After all, I have a lot of "weird" opinions which are not shared by "most of people", like not believing in "indicators", etc. (but it is also true that "most of people" leave their money at the exchange ) Anyway, as intellectual curiosity, I would like to hear more arguments supporting the "micro timeframes". ;-) Tom