TickZOOM Decision. Open Source and FREE!

Status
Not open for further replies.
Quote from greaterreturn:

Did you read the issues list?

There's only 2.

1 is a problem with tick speed. Someone was trying to use the software with 20 symbols at that same time in real time and couldn't do it.

That's not even back testing ticks.

TickZOOM runs in production collection 12 symbols with tick data and DEPTH of MARKET which is 10 to 100X as much data and uses almost zero CPU and very little memory.

That user couldn't get 20 stocks with only tick data to work.

And he was pointing out how much data it was, etc.

It has all the classic problems with handling tick data.

So what about all the GUI stuff. All the project do that stuff.

Anybody can write a GUI.

Wayne

Take a look here: http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/eSigTick.cs

and here:

http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/Bar.cs

Certainly it has nothing to do that with the fact it's written in C#, both you and I know that, but some readers should think a bit and do some research before they post :)
Now that I've reviewed some codes, I clearly think that the performance issues is caused by the design and the way Tick/ Bars is handled. No wonder that it couldn't handle 20 symbols!
 
Quote from janus007:

Take a look here: http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/eSigTick.cs

and here:

http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/Bar.cs

Certainly it has nothing to do that with the fact it's written in C#, both you and I know that, but some readers should think a bit and do some research before they post :)
Now that I've reviewed some codes, I clearly think that the performance issues is caused by the design and the way Tick/ Bars is handled. No wonder that it couldn't handle 20 symbols!

Strange that you would say that, considering no one has seen the source for tickzoom.

Have you seen the source to compare it with anything ? How can you say 'do research' against what is basically a closed source project? What 'research' have you done ?

Until greaterreturn actually posts some code, I think YOU should hold off doing any more 'research'.
 
Is the .tck file it is reading from a flat file or a database file ? I presume most users would want their data collected into some kind of database to make ongoing data updates easier and simulation runs involving subsets of the data more efficient.
 
Wayne - Very impressive so far. I had some issues with the mp4 format though. Although i resolved the, quickly, others may not be able to.

You may be able to upload the video to YouTube & link to it from there. I think Camtasia or Cam Studio can export videos in that format.

Eric

Quote from greaterreturn:

Announcement. The website is up and ready!

You can visit http://www.tickzoom.org to see the TickZOOM Speed Test video that demonstrates how fast it zooms through 10 million ticks with less than 100 megabytes of memory used.

But the site is coming together. I'll post back with any other major updates to the site.

And pippi, there was an illness in the family so I didn't get the documentation up there. How I made progress on it. Look for a lot of documentation later this week.

Sincerely,
Wayne
 
Quote from janus007:

Take a look here: http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/eSigTick.cs

and here:

http://code.google.com/p/tradelink/source/browse/trunk/TradeLib/Bar.cs

Certainly it has nothing to do that with the fact it's written in C#, both you and I know that, but some readers should think a bit and do some research before they post :)
Now that I've reviewed some codes, I clearly think that the performance issues is caused by the design and the way Tick/ Bars is handled. No wonder that it couldn't handle 20 symbols!

Agreed. I saw that too. Plus it has a ease of use issue in the Bar.cs but treating each "Bar" as a class and having an array of "bars" with high, med, low, close.

It should be designed as a single Bars class with array of High, Med, Low, Close (like T.Z.) so you can interchangeably use functions like Highest(High, 5) or Highest(Close,5), etc.

Good catch, Janus.

Wayne
 
Quote from Trader922:

Wayne - Very impressive so far. I had some issues with the mp4 format though. Although i resolved the, quickly, others may not be able to.

You may be able to upload the video to YouTube & link to it from there. I think Camtasia or Cam Studio can export videos in that format.

Eric

It sure can. I'll do that right this second and post back. Thanks for the idea!

Wayne
 
Quote from wenzi:

Strange that you would say that, considering no one has seen the source for tickzoom.

Have you seen the source to compare it with anything ? How can you say 'do research' against what is basically a closed source project? What 'research' have you done ?

Until greaterreturn actually posts some code, I think YOU should hold off doing any more 'research'.

Wenzi, I agree with your point. Thanks for your patience. Wayne!
 
Quote from Graham1:

Is the .tck file it is reading from a flat file or a database file ? I presume most users would want their data collected into some kind of database to make ongoing data updates easier and simulation runs involving subsets of the data more efficient.

Graham, thanks for asking. I know how you feel. I assumed the same thing originally and, as a database speed guru, I thought something would work.

Problem is that when reading 10Million ticks, if the database takes more then 1 microsecond to read each tick, then it will take foreever to load them.

At 10 microseconds, it takes 100 seconds or almost 2 minutes to load the file.

I found that even the fastest possible with OODBMS was about 30 to 50 microseconds.

Now, that's extremely fast compared to RDBMS but it's not fast enough for my taste at reading ticks.

Problem with those is they have overhead since they know how to do alot more than handle ticks.

I haven't completely give up on OODBMS. Especially if we use one that's open source.

Question is, will it be easier to just change on OODBMS to turn off all the functionality we don't need or just make our own data organization.

Noone has come up with any other query we need to do other than Symbol and time range.

So if we simply make a separate folder for each Symbol. And drop tick files in there which each have a "header" with the offset to every 10,000 tick boundary, that will be very fast and easy to work with since you just drop files there whether they cover 1 year, 6 months, 3 months, etc.

That's my thought at present and I'm open to well tested ideas in that area.

Sincerely,
Wayne
 
Quote from Graham1:

Is the .tck file it is reading from a flat file or a database file ? I presume most users would want their data collected into some kind of database to make ongoing data updates easier and simulation runs involving subsets of the data more efficient.

By the way, you're right, when we do what I described, we want to have the software interface just allow a drop down for symbols. Then the software finds the correct date range.

Wayne
 
Status
Not open for further replies.
Back
Top