VPS Hosting.

Quote from 314:

What you *would* miss if you went straight from NinjaTrader to a solely FIX-based solution is a lot of the niceties that NT affords you, such as the point-and-click interface, backtesting, strategy wizard (though I'm guessing you don't use that), etc. I've had to write a lot of ad-hoc code for backtesting and related activities, which was (is) fun for me, but may not be for everyone.
More...
Hi there,

Only thing I would really miss is back-testing, but it seems to me it shouldn't be too difficult (and probably superior in the long run) to implement my own solution there if necessary... or I can always backtest in NT, and run live outside of it.

Is QuickFIX working very reliably for you? What brokers has sample code available for easy integration? Or are all brokers about the same in terms of difficulty?
 
I should probably clarify here what MGB hinted at, and that is that FIX itself is a protocol used by multitudes of financial organizations for transmission of trades and related messages. QuickFix is an open-source library that speaks the FIX protocol, and can be called from a handful of languages. There are other libraries available, but most (all?) are commercial.

FIX works quite well for me. Most brokers that support it provide a protocol specification so that you know what unique commands they support and what specific requirements they have.
 
We moved to dedicated servers a couple years ago, and haven't looked back.

We started by renting dedicated servers at a colo service, but eventually found it much more cost effective and better in terms of control to get our own.

So what we ended up doing for our personal trading is to rent a half-rack which you can get for $500-$1000 per month.

We started with new servers, but quickly left them and went with used servers since the P3 core CPUs handled the math better than P4 cores.

So we ended up filling the half rack with 20 P3 based servers. A few are running SQL for data gathering and analysis, the others are running strategies, and feeding their results to SQL for dynamic and post analysis.

In the end, it's worth every penny. I don't worry about power, or internet connectivity ever. I can remote manage them all. We started out using RemotelyAnywhere and the free versions (which are great), especially since you can put more than one server on a single screen.

But more recently all the management has been automated too, so a single interface was all we needed and moved to Microsoft's Terminal Services.

The advantage is that is removes the distraction of the technology (power, internet, heat, etc) and shift your focus on the trading and analysis (where your focus should be.)

Even if you are trading a single strategy, it's worth a remote server. You can put the remote screen up on a laptop, and peek at it whenever you like, and not worry.

Our next move is to shift to the new quad cores since the extra cores may help shift some of the IO load away from the strategy execution.

Like another poster mentioned, the latency advantages (if you are a scalper which I am massively so) will pay for all your costs alone.

But the peace of mind (especially for us Forex folk) in all the 24 hours of the day is worth the cost all by itself.

Trader 5of7 @ TheCollectiveFX.com
 
I would talk to your broker or your clearing firm if you're directly connected to guys like BATS.

Obviously, each firm has their own preferred OMS / OES vendor they are connected to... and... the network firms (eg. Radianz) have their own set of hosts. Things go alot smoother if you deal with service vendors they're already dealing with. Also, the network latency and cost "may" be alot lower. In terms of getting support, it's alot easier for them to communicate within each other to deal with technical issues.

There are other benefits...

For starters, ask your broker and have a little chat with your firm's IT team or consultant. Unless you're dealing with a messed up firm, they're usually very helpful.
 
Quote from 314:

I wasn't sure which of us smodato was replying to, so at the risk of offering irrelevant information, here's a bit of info about my setup:

I'm running completely custom code, other than using the QuickFix libraries to provide the protocol link to my broker. My code is written largely in Ruby, runs on a FreeBSD system, and starts and stops itself automatically depending on time of day. I was fortunate to find a VPS provider (neither of the ones I mentioned earlier, though they're both great) with excellently low latency (18 ms) to my broker, so I execute all orders from there. I run the software inside a GNU screen session, so I can log in and attach or detach from that terminal at my whim.

I forward a database connection from one of my systems at home via a reverse SSH connection, in order to do long-term price and execution logging, but the DB queries for this are executed asynchronously, so they don't prevent actual trading activity from taking place when there is a bit of data transit delay.
More...
314...

Just to continue the conversation we were having way, way back when...

Are you familiar with the Rithmic API...? It seems interesting as an execution engine, because it specific targets low-latency engine.

I'm just wondering if I invest time in refactoring my code for a new order handling API (instead of Ninja)... if I should go with something like this, or QuickFIX.
 
I came across this the other day.

http://qwtradingsystem.com/

From their website, "QWFIX is provided in all flavors, pure .Net, pure Java and RTSJ (Real Time Java) for ultra high frequency trading. All three flavors share the same design, almost the same API and 100% interoperability. The C++ version (for exchanges and biggest broker/dealers) will be released soon."

I don't know the cost of the license.
 
Quote from MGB:

I came across this the other day.

http://qwtradingsystem.com/

From their website, "QWFIX is provided in all flavors, pure .Net, pure Java and RTSJ (Real Time Java) for ultra high frequency trading. All three flavors share the same design, almost the same API and 100% interoperability. The C++ version (for exchanges and biggest broker/dealers) will be released soon."

I don't know the cost of the license.
More...
That seems really interesting.

But I'm not wading into that pool and adopting a new platform like this without a lot of people around me. Who's going to take the first leap?
 
Quote from heech:

314...

Just to continue the conversation we were having way, way back when...

Are you familiar with the Rithmic API...? It seems interesting as an execution engine, because it specific targets low-latency engine.

I'm just wondering if I invest time in refactoring my code for a new order handling API (instead of Ninja)... if I should go with something like this, or QuickFIX.
More...

heech: Apologies for taking so long to get back to you. The short answer is that I'm not familiar with Rithmic's API. However I can vouch for FIX as being pretty universal, so if you do refactor your code to use it, you should be able to use any number of execution providers with only small changes.
 
You must log in or register to reply here.
Back
Top