TickZOOM Decision. Open Source and FREE!

Status
Not open for further replies.
Quote from greaterreturn:

Thanks for the info.



What do they send??

That was inconceivable to me until now. But obviously it's possible for broker to only provide a connection to place trades. Still it seems old, how do they know the bid/ask and last to track your account balance?

Oh maybe the have ticks but just don't provide them. Odd.

It's kind of cool the MB trading has such high quality tick data for free--just for having an account.

Wayen
More...

IB uses tick consolidation, at least in fast markets. I have seen estimates of a consolidation window of from 200 milliseconds to 2 seconds in fast markets. They apparently do this to avoid lagging the market. IB does not comment on this as far as I know. They also limit the number of symbols that can be watched. I don't know the limit. This may not bother some and I think it is fine for a backup but I, like you, want the data exactly as it comes from the exchange.

David
 
After just reading more about the TREE system. I feel more excited about that project.

Has anyone else read up on it? It seems to be "almost" exactly what is needed to store and organize ticks data.

They already have support of options and IB trading data as a data provider, etc.

I'm not certain why they say they only support a few platforms. GNU/C++ can support many different platforms.

I'm inclined to try to download an compile it as my first steps to get my feet wet with C++ again.

Their license is very open to reuse the code for any purpose. It's not even under the GPLv3.

Unfortunately, there's rarely any posts or response to their forums.

So it seems to be disuse.

Maybe TickZOOM can liven it up again!

Sincerely,
Wayne
 
Quote from greaterreturn:


TREE also defined a "standard symbol" set.

Unfortunately, right now, all the data vendors use different symbols for financial instruments.

That's very inconvenient.

One of the powerful forces at work in open source is "standardization". It has happened already in other industries that open source communities define a standard. Then even vendors adopted them as standard.

Without reviewing it in detail yet, I propose that we adopt the TREE standard for instrument symbols in TickZOOM.
More...

NinjaTrader's approach was to introduce the symbol maps. It defines the "master instrument" definition which is used in all the strategies and internally, and then maintains the "map" of each master instrument to each provider ( in case of different notation between master symbol and provider's symbol).

This approach makes sence, if you don't want to wait for "standartization" or till everyone will accept your standard.
 
Wow! I'm just reading the documentation for TREE to get a better idea of it's nature.

They have done a lot of discovery already and development in the area of "simultaneous" data feed between multiple provides.

There are major complexities in that area. Most of which they seemed to have solved.

Fascinating.

I wasn't aware of all the issues of dealing with the different formats of ticks, different correction formats, different symbol mapping, etc.

They apparently support real time tick feeds as well with they same type of aggregation we discussed here.

Since it's C++ it means it runs well on cheap Linus servers.

Here's an idea. Is there not someone who can take this up???? So I can focus on wrapping up the documentation and release.

Someone needs to download, compile it and try to make it connect to IB trading. I don't have an account yet.

You can do some rudimentary testing and then we can compare the tick format with TickZOOM.

My guess is that it will be better use the TREE tick format since they handle many of the symbol and provide issues already.

I sent email to the guy who posted the code on sourceforge. It bounced.

So I think we're on our own here for figuring it out. There's decent documentation with the code on Subversion if you want to read up on it.

They handled Reuters and Comstock data feeds also. I'm guessing those are high dollar commercial ones.

They were collecting over 1200 symbols in real time at one point.


Wayne
 
Folks, I want to get an IB trading connection setup pretty quickly.

I just noticed they support FIX.

Do they charge extra for it, etc?

If not, that's a far better/standard interface. And I could more quickly implement a solution to do it with FIX.

Wayne
 
Quote from vladisld:

NinjaTrader's approach was to introduce the symbol maps. It defines the "master instrument" definition which is used in all the strategies and internally, and then maintains the "map" of each master instrument to each provider ( in case of different notation between master symbol and provider's symbol).

This approach makes sence, if you don't want to wait for "standartization" or till everyone will accept your standard.
More...

Certainly, that must be the approach. Sorry, I took that as a given and failed to mention it.

What I mean is that when we're exchanging tick files as user, etc.

We need the tick format in those files to be a standardized.

One area is that Timestamp. I'm using, of course, UTC time as the international standard.

Since there's no international symbol standard, we'll have to map them but the ticks should always be in a defined standard. That will make it 1000X easier to write the "mapping code".

That way the mapping code is always converting symbols between vendor and TickZOOM and TickZOOM and vendor. But never between vendor A to vendor B.

Sorry I wasn't clear. That geometrically reduces the number of combinations.

Now, do you propose we use the standard symbols as NinjaTrader?
 
Quote from greaterreturn:

Folks, I want to get an IB trading connection setup pretty quickly.

I just noticed they support FIX.

Do they charge extra for it, etc?

If not, that's a far better/standard interface. And I could more quickly implement a solution to do it with FIX.

Wayne
More...

FIX is certainly better then any proprietary interface just because it is some sort of standard and could be used not just for IB. Unfortunately IB charges 10 time more (then their proprietary API ) for using FIX - may be because it's kind of 'more professional' way of trading.

Look at their site:
http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
 
Quote from vladisld:

FIX is certainly better then any proprietary interface just because it is some sort of standard and could be used not just for IB. Unfortunately IB charges 10 time more (then their proprietary API ) for using FIX - may be because it's kind of 'more professional' way of trading.

Look at their site:
http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
More...

Yeah, I studied their site. I'm curious are you willing to pay the $500 setup and $100 a month?

They don't really support C++ on Linux for their proprietary API which is what I was hoping.

It seems the only support Java or .Net languages.

I agee that Java will be the better choice. Someone contacted me about doing himself the development in Java.

I wanted to do a little research on this.

That seems the best option at this point. It can talk to TickZOOM over a tcp/ip pipe with the tick data.

Several say it's a good design to use a tcp/ip pipe since it allows easier inter language operation.

Hmm. Fix can be added also, you just need some simple code to connect the fix client, query the ticks and send them over tcp/ip to TickZOOM.

Anyway, I see that Java for IB is the right choice and will forward the info this evening so the developer can work on that while I finish documenting and setting up the code for release.

Sincerely,
Wayne
 
I notice this guy has done a native C# implementation of the IB API :

http://www.dinosaurtech.com/utilities/

I have never tried using it myself. It might be worth considering.

One thing I have heard is that IB make changes from time to time to the underlying protocol that passes across the network - so if any non-IB code is used to implement that protocol it is important that the developers keep it regularly updated.
 
Status
Not open for further replies.
Back
Top