SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
HockeyPlayer
Topic Author
Posts: 18
Joined: June 4th, 2008, 12:26 pm

Lets talk about speed

June 4th, 2008, 2:23 pm

I’m investigating building an arbitrage system for use in the futures markets. I’m interested to know how fast such a system should be.Say I use a third-party framework, such as Apama, ORC’s Liquidator, Reactor, etc. Let’s measure total elapsed time from when a fill message arrives at the computer's network card to when the covering order message leaves that computer. How fast would a system built with the above packages be? Assume that my business logic of sending the cover out is quite simple; e.g., I bought one at 30, sell one at 40. Are we talking 5 ms, 1 ms, .5 ms?Is that time fast enough? How fast do I need to go to be the fastest thing out there?
 
User avatar
DominicConnor
Posts: 11684
Joined: July 14th, 2002, 3:00 am

Lets talk about speed

June 4th, 2008, 3:53 pm

Depends quite a lot on the your market and strategy, I see people working at 1ms to 1 second.But you're building now to deliver in a faster future.At a meeting today, we were looking at next generation stuff where latency was measured in microseconds, some of the tech is just weird, so not quite what you're looking at.You need to look also at the time it takes to get from your system to the counterparty. That can screw you big time, there is a strong correlation between size of firm and infrastructure latency. If you don't work at JP Morgan, your bank's network was built to handle email, Reuters and Bloomberg. If you're at JPM, the network was built specifically to be crap so they could charge to fix it.Then it has to get to the counterparty, that can be slower than you want, you may have to look at colocation.Although the tools you cite are sensible choices, by definition they are not going to deliver competitive advantage. Everyone can buy them, you need to decide what balance of investment non-standard technology and better algorithms.If you want to be the fastest, you will need a serious budget. Inter alia, you need a purpose built network infrastructure, that's not just "speed", but predictable latency.You then need an entertaining computer-like gadget from the OS/2 group that can do the task you describe in nanoseconds (OK, a lot of nS, but one's intuition as to time gets blurry here.To drive this shit, you need the right Linux setup, which will deal with the slow moving millsecond level shit.Then to do calculations you have to make tough calls between FPGA, GPU/PPU and Clearspeed, possibly some scary combination.This is all buildable/buyable now.But this is like Formula One racing, few people really need that level of performance.An F1 car goes less than twice the speed of my nanny's car, but costs 30 times as much.Actually, most people could not drive a F1 car at all, they literally could not get it round one lap. Nearly all the money made from algotrading comes from equipment not very different from the web server running this site, so you proably will go down that route.
Last edited by DominicConnor on June 3rd, 2008, 10:00 pm, edited 1 time in total.
 
User avatar
farmer
Posts: 13479
Joined: December 16th, 2002, 7:09 am

Lets talk about speed

June 4th, 2008, 6:39 pm

QuoteOriginally posted by: outrunIf Paul would spend a single day of banner revenues on buying a new server, than that would be earned back within a couple of days.I don't know. There are a lot of posts in this forum. For all you know, the forum code is written to retrieve every single post from the database or something dumb like that, and then only turn the first 20 into a page. Or maybe the keyword searches are pushed through the cold fusion parsing engine somehow, in a way that slows the whole site down. Or maybe spiders are hitting the thing 10 times a second, and Wilmott likes to accommodate the spiders.It's complicated to prioritize threads well on Linux, so far as I know. And 99% of the customers of out-of-box forum software will only ever get 10 posts. So it might be the whole forum script needs to be rewritten. Who the heck uses cold fusion anyway?
 
User avatar
katastrofa
Posts: 9665
Joined: August 16th, 2007, 5:36 am
Location: Alpha Centauri

Lets talk about speed

June 5th, 2008, 8:13 pm

@farmerJoel on Software is also a popular forum. It's run by some in-house code. It's amazingly fast as compared to this one.
 
User avatar
asdf
Posts: 28
Joined: July 14th, 2002, 3:00 am

Lets talk about speed

June 10th, 2008, 3:53 pm

3 important elements in Algo / Script trading to beat the competition running the same scripts:- place your server as close to the exchange as possible - then you will reach a good latency- Coding, convert all formulas to Nvidia Cuda and parallel execution (if they are suited for this)- Buy the biggest hammer (PC) you can get - (Intel SkullTrail, 4 times Nvidia graphics board)Above is simplified, but these are the main elements you can adjust
 
User avatar
farmer
Posts: 13479
Joined: December 16th, 2002, 7:09 am

Lets talk about speed

June 10th, 2008, 10:05 pm

Why not just run a neural network on your network connection? If you are in state 345, and you get the front seven bits 1110100, that indexes to a reaction of return bit seqence CA34RT1.
 
User avatar
HockeyPlayer
Topic Author
Posts: 18
Joined: June 4th, 2008, 12:26 pm

Lets talk about speed

June 16th, 2008, 8:14 pm

Thanks for the responses, especially the relevant ones. The forum software is lousy, but the content is often useful.
 
User avatar
endian675
Posts: 143
Joined: March 11th, 2008, 7:09 pm

Lets talk about speed

July 11th, 2008, 11:06 am

Solution: take the people and the content, and populate a new server somewhere!
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On