Shared Massive Parrallel Tick Testing System?

Quote from greaterreturn:

Yes, I agree. What will help is when i have the website up where people can post these issues as "research".

I realize you can't see the system or code yet. But it's only a stones through from doing most of this stuff.

All I have left to do now before releasing it is refactor the API to custom code. The way I have it at the moment won't be too forward compatible. I have a better way.

Maybe I should go incognito till I finish? That's a fair point.

Wayne
No probs Wayne. All the best with this.

Cheers.
 
why not just have the feature built into tickzoom? that way each user could share processing power with other users. if you dont share your computer, you dont get access to others'.
 
Frostengine. You make some interesting points. Worth thinking about.

Quote from frostengine:


If you decided to go the route of building your own server farm for this. Which wouldn't be a bad idea. To have a server farm dedicated specifically for TickZoom.. one issue you will run into is the data.... To share data with users like this, especially 5 years worth of tick data is VERY expensive. Data vendors charge INSANE amounts of money if you are planning to share your data... Which if you had a server farm like this, it would make sense to have all the data already available....Just something to think about..

For instance I've recently gotton quotes in the range of $12k a year just for END Of day data to be shared...

I imagine tick level would be MUCH MUCH larger...

Then again if you have a few thousand "subscribers" to your server farm it may not be.... but if your looking at < 100 subscribers, data cost will eat you alive...
 
Again, very interesting.

Quote from auspiv:

why not just have the feature built into tickzoom? that way each user could share processing power with other users. if you dont share your computer, you dont get access to others'.
 
You have hit the nail on the head exactly. I've been doing what's called "requirements gathering" using these forums.

Originally, I wrote TickZOOM only thinking of my personal requirements. Opening this up wide open for a week or two helps me have sense of where to go.

One good example is that before last Tuesday I was assuming it would be laughed at due to the very simple user interface although it does make very nice easy to use charts.

But the overwhelming response here is the opposite. Virtually everyone says the value is in the very fast engine.

That has totally changed my focus and accelerated when I can deliver the first release because I HAVE the engine working just fine.

Plus people asked about the limitations in other software which will be relatively easy to add in TickZOOM due to the architecture.

So it's all good.

But the number of comments like your of "get it finished already" are starting to pile up so I'm answering posts more briefly now.

The project description and road map is pretty solid now (not many disagreeing with it) so other than adding to the wish list. I'm finished gathering requirements for now.

Sincerely,
Wayne

Quote from Equalizer:

Dude, no disrespect, but I'm seeing "headless chicken syndrome" here.

I have read your posts here as of recent, and you have some good ideas, but I see a classic example of feature creep before the project has even began.

Define a subset of deliverables that make sense and are achievable, and make a start. You can add all the fairy dust you wish for later.

Yes you do have to plan for some features from now, otherwise there could be major architectural rework further down the track, but you need to make a start and not let this turn into analysis-paralysis and an acute case of featurecreepitis (the mother of all trading SW).


Just MHO.
 
FYI, the last several discussions have added C++ port and massive parrallel computing to the road map. It's obvious that serious users will be willing to pay something reasonable (probably less than popular closed source commercial platforms) for the add-ons of parrallel computing and other "power user" features. Those will help fund a support team and development of the project as a whole.

And you're right it's important to have a direction of where the project is headed both for me and users.

Thanks. Wayne

Quote from Equalizer:

Dude, no disrespect, but I'm seeing "headless chicken syndrome" here.

I have read your posts here as of recent, and you have some good ideas, but I see a classic example of feature creep before the project has even began.

Define a subset of deliverables that make sense and are achievable, and make a start. You can add all the fairy dust you wish for later.

Yes you do have to plan for some features from now, otherwise there could be major architectural rework further down the track, but you need to make a start and not let this turn into analysis-paralysis and an acute case of featurecreepitis (the mother of all trading SW).


Just MHO.
 
Back
Top