I can do that, but normally I only bother doing it for prospective clients. I'm indifferent if you believe the numbers or not, but anyway see an excerpt attached.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Any good structure for a simple self-made backtesting platform?
- Thread starter j2ee
- Start date
I can do that, but normally I only bother doing it for prospective clients. I'm indifferent if you believe the numbers or not, but anyway see an excerpt attached.
Quote from QuantWizard:
I can do that, but normally I only bother doing it for prospective clients. I'm indifferent if you believe the numbers or not, but anyway see an excerpt attached.
Why do you even reply do that douche bag? Everyone at et.com is laughing at him. Just ignore him and also laugh about every of his new monologs. There nearly is no better comedy available!
Quote from j2ee:
I don't expect my database to be anything close to 10GB limit yet so it is fine for me for now.
Really? What do you backtest? 1 market, 1 strategy, 1 set of parameters fof 1 month?
My current backtest database of the last month has 1.06 billion trades stored which is - compressed with the table compression feature of sql server non-free - 30gb, plus 1.7 billion executions in 52gb (not compressed). That is new since a schema change about 2 weeks ago. When "hitting the computers" we add about 100 million trades per 24 hour period - sometimes more, sometimes less.
The bar data we generate for visualizations (charts) and that is 1 minute (note: this is not what is traded- just for visualizing) has (and there are gaps - the routine has issues, this is a new code part, part of the "lets see things fast on a graph") has 94 milllion rows in (compressed) 3.4gb. That is 80% compressed - a feature the free version does not have.
Note that all that does not count the 340gb of compressed tick data - that is outside the database. Heck, my backtest work control tables cover 600mb already with 1.8 million tasks that were executed.
Seriously, assuming 10gb is going to last means you are not using any sensible set of backtests and optimizations.
If I were you I would get:
* a proper scalable database. Not saying "download an illegal copy" but you HAVE to have something that scales.
* Remember to get a nice 512gb SSD for the data, as a start.
But assuming you can run that on 10gb means you have to throw away results pretty much immediately (the ninja trader model).
I just trade one market and I have my own reason. If you trade thousands of stocks, very big database makes sense.
Quote from NetTecture:
Really? What do you backtest? 1 market, 1 strategy, 1 set of parameters fof 1 month?
My current backtest database of the last month has 1.06 billion trades stored which is - compressed with the table compression feature of sql server non-free - 30gb, plus 1.7 billion executions in 52gb (not compressed). That is new since a schema change about 2 weeks ago. When "hitting the computers" we add about 100 million trades per 24 hour period - sometimes more, sometimes less.
The bar data we generate for visualizations (charts) and that is 1 minute (note: this is not what is traded- just for visualizing) has (and there are gaps - the routine has issues, this is a new code part, part of the "lets see things fast on a graph") has 94 milllion rows in (compressed) 3.4gb. That is 80% compressed - a feature the free version does not have.
Note that all that does not count the 340gb of compressed tick data - that is outside the database. Heck, my backtest work control tables cover 600mb already with 1.8 million tasks that were executed.
Seriously, assuming 10gb is going to last means you are not using any sensible set of backtests and optimizations.
If I were you I would get:
* a proper scalable database. Not saying "download an illegal copy" but you HAVE to have something that scales.
* Remember to get a nice 512gb SSD for the data, as a start.
But assuming you can run that on 10gb means you have to throw away results pretty much immediately (the ninja trader model).
Quote from NetTecture:
Really? What do you backtest? 1 market, 1 strategy, 1 set of parameters fof 1 month?
My current backtest database of the last month has 1.06 billion trades stored which is - compressed with the table compression feature of sql server non-free - 30gb, plus 1.7 billion executions in 52gb (not compressed). That is new since a schema change about 2 weeks ago. When "hitting the computers" we add about 100 million trades per 24 hour period - sometimes more, sometimes less.
The bar data we generate for visualizations (charts) and that is 1 minute (note: this is not what is traded- just for visualizing) has (and there are gaps - the routine has issues, this is a new code part, part of the "lets see things fast on a graph") has 94 milllion rows in (compressed) 3.4gb. That is 80% compressed - a feature the free version does not have.
Note that all that does not count the 340gb of compressed tick data - that is outside the database. Heck, my backtest work control tables cover 600mb already with 1.8 million tasks that were executed.
Seriously, assuming 10gb is going to last means you are not using any sensible set of backtests and optimizations.
If I were you I would get:
* a proper scalable database. Not saying "download an illegal copy" but you HAVE to have something that scales.
* Remember to get a nice 512gb SSD for the data, as a start.
But assuming you can run that on 10gb means you have to throw away results pretty much immediately (the ninja trader model).
Question: Where do you get the tick data from? Nanex? Which database are you using at the moment? How do you rate MS SQL vs. MySQL?
Quote from j2ee:
I just trade one market and I have my own reason. If you trade thousands of stocks, very big database makes sense.
We trade 15 markets. Futures only. Point is - 10 giga is NOTHING if you go for a higher data density. We even improove that (going to store every status change on an order and execution soon). Optimizations do a LOT of variations thus a LOT of trades.