Can anyone shed some light on the kind of technology/IT Infrastructure is used at their HF/electronic trading execution firm? If someone has coded some strategy, do they need BIG servers for fast computation or sometimes, even simple small tower servers work fine ... ??

They co-locate and a quad core is probably good enough depending on how many securities they are trading at any given exchange. Co-location and latency are usually the biggest two factors. They might have a cluster behind the scene which they use to run simulations but it's not part of the real time trading engine.

Our simulation boxes are quite robust - dual CPU towers with lots of RAM. Execution boxes are a completely different story. My stuff isnt exactly HFT but I do need execution speed. I use E8400 and Q9650 CPUs in dell Optiplex 755 towers and run XPx64 with 8GB ddr2 RAM. The boxes are very simple and just have an OS and the execution software installed. Some of the boxes that are pricing out things like the russell3000 are dual CPU boxes with 24GB RAM which is probably overkill but I'm having some issues with that much data so I wanted to rule out the hardware. I run RAID0 on two 500GB drives short-stroked down to 120GB each, giving me about 250GB total. We have played with SSD but have found that RAM Drives are easier and faster. i7's eliminate the FSB so RAM is controlled directly by the CPU.

QuoteOriginally posted by: winstontjOur simulation boxes are quite robust - dual CPU towers with lots of RAM. Execution boxes are a completely different story. My stuff isnt exactly HFT but I do need execution speed. I use E8400 and Q9650 CPUs in dell Optiplex 755 towers and run XPx64 with 8GB ddr2 RAM. The boxes are very simple and just have an OS and the execution software installed. Some of the boxes that are pricing out things like the russell3000 are dual CPU boxes with 24GB RAM which is probably overkill but I'm having some issues with that much data so I wanted to rule out the hardware. I run RAID0 on two 500GB drives short-stroked down to 120GB each, giving me about 250GB total. We have played with SSD but have found that RAM Drives are easier and faster. i7's eliminate the FSB so RAM is controlled directly by the CPU.interesting choice of OS. any particular reason why you went the windows route?

QuoteOriginally posted by: WannaArbinteresting choice of OS. any particular reason why you went the windows route?Because I love cursing and yelling at MSFT every Wednesday morning at 3am when they roll out updates and do a forced restart??? I'd say because its easy & free but that's not true either. Went with XPx64 because with w7 came cheap licenses for xp64 and because many of my software vendors (probably also offer a Unix/Linux solution but I'm too lazy to deal with it) offer very good support for windows and because I'm not one user, I'm one of five people working with the boxes and its an easy standard that everyone knows. XPx64 is an excellent platform IMO and very stable. I've done side by side testing with xp64 vs w7 and I'm not impressed. I'll stick to xp64 until w7sp1 or sp2.

On average we do 5-15min forecasts and the closest we ever tend to trade is about every 20s or so (so not *high* frequency). We are using dual X55** Xeon chips (which use ECC memory) for each computer. The main algorithm is easy to parallelize, hence the two processor choice - if the algorithm didn't parallelize nicely we'd have bought a W55** chip at the time instead. Our calculation computers have mirrored SATA drives and don't need SSD as it doesn't write to the disk when time is critical (i.e. when it is/is about to trade)."My stuff isnt exactly HFT but I do need execution speed. I use E8400 and Q9650 CPUs"Doesn't that mean you aren't using ECC memory and so could randomly have a bit flip? I accept this is unlikely to happen, but to save $1k or something, I don't understand how that is a risk worth taking. Considering the P&L fluctuations of the strategies, $1k is minimal. Maybe I worry too much about the ECC ram issue - do other people not use ECC?thanksMG

Correct, non-ECC memory. My execution software is a single-thread application so thats why an E8400=Q9650 when only using one core. In some cases an E8600 > Q9650 but for the money it doesn't make sense when you can repurpose the q9650 to a general workstation box later on. We aren't on a shoe strings and duct tape budget but everything is run out of boxes vs. racks at the moment. When I move over to racks I'll look into some of that. Do you run money for others? My setup is an asset pool/LLC with a few guys - we don't have investors so anything we make/lose is our own money. Because of that we don't need to be overkill about backup/redundancy like some others might need to be. Our code and programs don't break/freeze - or haven't yet. I don't know what else to say other than its just not a concern and we just don't worry about it. You'd be supprised what a little E8400 with 8GB DDR2 RAM can do. QuoteOriginally posted by: mg298"My stuff isnt exactly HFT but I do need execution speed. I use E8400 and Q9650 CPUs"Doesn't that mean you aren't using ECC memory and so could randomly have a bit flip? I accept this is unlikely to happen, but to save $1k or something, I don't understand how that is a risk worth taking. Considering the P&L fluctuations of the strategies, $1k is minimal. Maybe I worry too much about the ECC ram issue - do other people not use ECC?thanksMG

QuoteOriginally posted by: winstontjQuoteOriginally posted by: WannaArbinteresting choice of OS. any particular reason why you went the windows route?Because I love cursing and yelling at MSFT every Wednesday morning at 3am when they roll out updates and do a forced restart??? I'd say because its easy & free but that's not true either. Went with XPx64 because with w7 came cheap licenses for xp64 and because many of my software vendors (probably also offer a Unix/Linux solution but I'm too lazy to deal with it) offer very good support for windows and because I'm not one user, I'm one of five people working with the boxes and its an easy standard that everyone knows. XPx64 is an excellent platform IMO and very stable. I've done side by side testing with xp64 vs w7 and I'm not impressed. I'll stick to xp64 until w7sp1 or sp2.So is that what you use for execution. Are these computers fast enough to do your execution? I wonder why websites like advanced trading give the image that every other shop/hedge fund uses big ass customized software that does their work and settles their trade.So can fast execution be done on a windows system? Latency is not an issue for you in this case? I thought most hedge funds use Unix for execution in order to have fast calculation and avoid price slippage.

QuoteOriginally posted by: mg298On average we do 5-15min forecasts and the closest we ever tend to trade is about every 20s or so (so not *high* frequency). We are using dual X55** Xeon chips (which use ECC memory) for each computer. The main algorithm is easy to parallelize, hence the two processor choice - if the algorithm didn't parallelize nicely we'd have bought a W55** chip at the time instead. Our calculation computers have mirrored SATA drives and don't need SSD as it doesn't write to the disk when time is critical (i.e. when it is/is about to trade)."My stuff isnt exactly HFT but I do need execution speed. I use E8400 and Q9650 CPUs"Doesn't that mean you aren't using ECC memory and so could randomly have a bit flip? I accept this is unlikely to happen, but to save $1k or something, I don't understand how that is a risk worth taking. Considering the P&L fluctuations of the strategies, $1k is minimal. Maybe I worry too much about the ECC ram issue - do other people not use ECC?thanksMGSo trading every 20 seconds is not HF?? Mind if I ask what type of software do you use? Am I correct to guess that you are using some API provided to you by your broker(s)?

"So trading every 20 seconds is not HF??"we can trade up to every 20s, but that's about as fast as we ever get - usually we are doing much less than this. There seems to be a lot of different interpretations of what high frequency means, and I have read about algos trading at significantly higher frequency than ours do, so I try to avoid describing us as very high frequency - some people get sensitive about this."Our code and programs don't break/freeze - or haven't yet" (in reference to ECC memory)what concerns me with algos using non-ECC isn't that they will freeze, it's that a bit will flip on something related to the size of an order and we'll trade a boat load of something we don't really want - I'd hope our other systems would catch this, but if the extra cost is small compared to algo P&L, I'd rather go for ECC and would advise this."Do you run money for others?"yes, the fund has (limited) external £$£ (it used to be much more) and internal £$£.Software: C/C++ in visual studio, trading through FIX with a few different brokers. We have a 3rd party company that deals with the lowest level FIX stuff (such as converting to the correct FIX version for each broker). I would rather have run our algo in Linux but have a really old MS SQL database and much of the code written over the years was Windows specific so moving away from it isn't trivial (and gets harder every day...). I'd have thought Windows 7 wouldn't be a million miles behind most versions of Unix/Linux for most tasks apart from perhaps network traffic - this is not a *massive* concern for us as we aren't that high frequency that we need to shave off 10ms here or there. Threading may be a bit better on Linux too, but (atm atleast) for us we don't think this is significant enough to warrant the change for our algorithm. If we were desperate for more speed, initially we'd consider the ICC compiler in windows first, as that's an easier alteration and in the past gave some improvements."So can fast execution be done on a windows system? Latency is not an issue for you in this case?"I think the answer to this depends on how high frequency you are talking about. If you are talking about ultra high frequency, then windows is not suitable as a 5-10 milliseconds here or there presumably becomes significant. If you don't have co-location and/or don't think 50ms would have much impact on algo performance and you prefer windows, then I think Windows should be fine; so far for us it has - our P&L is hugely dominated by good/bad trade decisions (from the algo itself) rather than not getting filled on something as someone was a shade faster. Sorry for the slightly non-committal answer. Out of interest - what price feed do you plan on using for your algo?

QuoteOriginally posted by: mg298"So trading every 20 seconds is not HF??"we can trade up to every 20s, but that's about as fast as we ever get - usually we are doing much less than this. There seems to be a lot of different interpretations of what high frequency means, and I have read about algos trading at significantly higher frequency than ours do, so I try to avoid describing us as very high frequency - some people get sensitive about this.I see what you are saying and yes I've come across those too (annoying.... ). I personally think that if its too fast for a human to execute then its High Frequency. But then there are some from the big banks/funds who think that if your not executing XXX many shares every minute then you are not high frequency. I also found that in general there also seems to be a bit vagueness about high frequency and automated trading..... Quote "Our code and programs don't break/freeze - or haven't yet" (in reference to ECC memory)what concerns me with algos using non-ECC isn't that they will freeze, it's that a bit will flip on something related to the size of an order and we'll trade a boat load of something we don't really want - I'd hope our other systems would catch this, but if the extra cost is small compared to algo P&L, I'd rather go for ECC and would advise this."Do you run money for others?"yes, the fund has (limited) external £$£ (it used to be much more) and internal £$£.After seeing you being so conscious about ECC (and thanks for your honesty here), I'm starting to get a little concerned about it as well. HAve you ever come across a problem where your system just drops and fails due to RAM errors. IS ECC memory suppose to be any better/faster?QuoteSoftware: C/C++ in visual studio, trading through FIX with a few different brokers. We have a 3rd party company that deals with the lowest level FIX stuff (such as converting to the correct FIX version for each broker). I would rather have run our algo in Linux but have a really old MS SQL database and much of the code written over the years was Windows specific so moving away from it isn't trivial (and gets harder every day...). I'd have thought Windows 7 wouldn't be a million miles behind most versions of Unix/Linux for most tasks apart from perhaps network traffic - this is not a *massive* concern for us as we aren't that high frequency that we need to shave off 10ms here or there. Threading may be a bit better on Linux too, but (atm atleast) for us we don't think this is significant enough to warrant the change for our algorithm. If we were desperate for more speed, initially we'd consider the ICC compiler in windows first, as that's an easier alteration and in the past gave some improvements."So can fast execution be done on a windows system? Latency is not an issue for you in this case?"I think the answer to this depends on how high frequency you are talking about. If you are talking about ultra high frequency, then windows is not suitable as a 5-10 milliseconds here or there presumably becomes significant. If you don't have co-location and/or don't think 50ms would have much impact on algo performance and you prefer windows, then I think Windows should be fine; so far for us it has - our P&L is hugely dominated by good/bad trade decisions (from the algo itself) rather than not getting filled on something as someone was a shade faster. Sorry for the slightly non-committal answer. Out of interest - what price feed do you plan on using for your algo?To be honest, we just back tested our system and are in the stages of taking it for LIVE testing. We are still deciding on price feed and brokers. We are starting very small for now. No external money. For now I was thinking that a Lenovo TD 200x (Quad Core) should be fine. However, someone gave us the impression that you need RACKS AND RACKS of computing power to do High Frequency trading.... though I don't see why would we need that unless we trade every exchange 24/7. Btw, we are trying to shave down 5-10 ms wherever we can. So if a linux server helps then I can guess I should start looking into that option. Although I'd hate to deal with Unix and linux since windows is much more simpler. May I ask that what sort of storage requirements do you happen to have with your setup?After the above discussion, I guess more intense computers are needed for running simulations and strategy discovery as oppose to actually executing the trade.

So overall, does the investment in technology infrastructure need to be INSANE (and I mean tens of thousands of dollars) in order to execute only one strategy for HF trading? Or that's just the Myth?

QuoteOriginally posted by: BornToBeTraderQuoteOriginally posted by: mg298"So trading every 20 seconds is not HF??"we can trade up to every 20s, but that's about as fast as we ever get - usually we are doing much less than this. There seems to be a lot of different interpretations of what high frequency means, and I have read about algos trading at significantly higher frequency than ours do, so I try to avoid describing us as very high frequency - some people get sensitive about this.I see what you are saying and yes I've come across those too (annoying.... ). I personally think that if its too fast for a human to execute then its High Frequency. But then there are some from the big banks/funds who think that if your not executing XXX many shares every minute then you are not high frequency. I also found that in general there also seems to be a bit vagueness about high frequency and automated trading..... Quote "Our code and programs don't break/freeze - or haven't yet" (in reference to ECC memory)what concerns me with algos using non-ECC isn't that they will freeze, it's that a bit will flip on something related to the size of an order and we'll trade a boat load of something we don't really want - I'd hope our other systems would catch this, but if the extra cost is small compared to algo P&L, I'd rather go for ECC and would advise this."Do you run money for others?"yes, the fund has (limited) external £$£ (it used to be much more) and internal £$£.After seeing you being so conscious about ECC (and thanks for your honesty here), I'm starting to get a little concerned about it as well. HAve you ever come across a problem where your system just drops and fails due to RAM errors. IS ECC memory suppose to be any better/faster?QuoteSoftware: C/C++ in visual studio, trading through FIX with a few different brokers. We have a 3rd party company that deals with the lowest level FIX stuff (such as converting to the correct FIX version for each broker). I would rather have run our algo in Linux but have a really old MS SQL database and much of the code written over the years was Windows specific so moving away from it isn't trivial (and gets harder every day...). I'd have thought Windows 7 wouldn't be a million miles behind most versions of Unix/Linux for most tasks apart from perhaps network traffic - this is not a *massive* concern for us as we aren't that high frequency that we need to shave off 10ms here or there. Threading may be a bit better on Linux too, but (atm atleast) for us we don't think this is significant enough to warrant the change for our algorithm. If we were desperate for more speed, initially we'd consider the ICC compiler in windows first, as that's an easier alteration and in the past gave some improvements."So can fast execution be done on a windows system? Latency is not an issue for you in this case?"I think the answer to this depends on how high frequency you are talking about. If you are talking about ultra high frequency, then windows is not suitable as a 5-10 milliseconds here or there presumably becomes significant. If you don't have co-location and/or don't think 50ms would have much impact on algo performance and you prefer windows, then I think Windows should be fine; so far for us it has - our P&L is hugely dominated by good/bad trade decisions (from the algo itself) rather than not getting filled on something as someone was a shade faster. Sorry for the slightly non-committal answer. Out of interest - what price feed do you plan on using for your algo?To be honest, we just back tested our system and are in the stages of taking it for LIVE testing. We are still deciding on price feed and brokers. We are starting very small for now. No external money. For now I was thinking that a Lenovo TD 200x (Quad Core) should be fine. However, someone gave us the impression that you need RACKS AND RACKS of computing power to do High Frequency trading.... though I don't see why would we need that unless we trade every exchange 24/7. Btw, we are trying to shave down 5-10 ms wherever we can. So if a linux server helps then I can guess I should start looking into that option. Although I'd hate to deal with Unix and linux since windows is much more simpler. May I ask that what sort of storage requirements do you happen to have with your setup?After the above discussion, I guess more intense computers are needed for running simulations and strategy discovery as oppose to actually executing the trade.If you're looking to shave 5-10ms then I assume latency is all important to your algo. If so, you're going to need coloc, direct exchange feeds, kdb, historical level 2 data, linux server etc., i.e. the works.... unless you're trading relatively illiquid securities whereby you can probably get away with a lot less.

QuoteOriginally posted by: BornToBeTraderHave you ever come across a problem where your system just drops and fails due to RAM errors. IS ECC memory suppose to be any better/faster?I have had a non ECC memory live trading computer crash before it was supposed to be trading; it was a converted desktop and had a dodgy memory stick. We soon moved to an ECC Xeon based server. http://news.cnet.com/8301-30685_3-10370026-264.html details a Google investigation into errors in ECC memory and how it often manages to fix the error. We have about 20 desktops at our company of which we have detected (via user complaints) 3 memory sticks which have broken in the last 2 years. This has not happened for any of our ECC memory sticks that we are aware of (though we will have less sticks of ECC than we do non-ECC). The parity of ECC makes it better for reliability and (slightly) slower than non-ECC.QuoteOriginally posted by: BornToBeTraderMay I ask that what sort of storage requirements do you happen to have with your setup?Sure - we have a slow price data database which is raid5 SATA. Anything that trades live initially pulls it off here and caches it in memory (and on the local hd). This makes it fast (ish) when live (through memory) and faster to restart (as it doesn't need to pull info off the slow db and can get what it needs locally). Live trades are stored in a smaller different db on the execution machine - this db is able to fit in memory and is flushed out (daily ish) to disk.If you are going to go the Unix route through necessity (rather than personal preference), you probably should think carefully about what data feed you are going to use and how you are going to execute trades (i.e. how your messages get to the exchange). It sounds like a standard BBG feed won't be suitable at all due to the latency.QuoteOriginally posted by: BornToBeTraderSo overall, does the investment in technology infrastructure need to be INSANE (and I mean tens of thousands of dollars) in order to execute only one strategy for HF trading?Computer hardware wise I don't think the cost would be insane. My boss tells me co-location needn't be too expensive if done through a broker (i.e. rent space through the broker who manages many clients co-location in the same room) but you'd need a fast data feed and I am unsure how people get feeds if they are next to the exchange, whether it comes directly from the exchange or if they must pay another party for it. I expect this could cost a fair wack. Bear in mind we haven't done this, so I could be wrong; I am slightly out of my depth when it comes to ultra high frequency stuff.

Quote If you're looking to shave 5-10ms then I assume latency is all important to your algo. If so, you're going to need coloc, direct exchange feeds, kdb, historical level 2 data, linux server etc., i.e. the works.... unless you're trading relatively illiquid securities whereby you can probably get away with a lot less.Actually, we are looking at Fixed Income, Currencies and FX options. Most of them being the most liquid instruments on the market. Especially FX. So yea, we are going to need the works. Now, all I have to figure out is what is included in the works. Can anyone please recommend somethings wrt this? Should we go with Red Hat Linux server? Should we have much faster servers with multiple processors? We were thinking of getting the T1 service for this one but other than that, I'm not sure what else can we do there to avoid latency over the network. not mention that everything was coded in Visual C++ so far. Not sure how much is gonna change wrt memory management.