TickZOOM Decision. Open Source and FREE!

Status
Not open for further replies.
Folks,

Your help is needed. Some documentation on the API between your custom code and the TickZOOM engine now is on the wiki.

Your help is needed in commenting on the names and especially help with naming one of them because one name "Formula" was used for two purposes.

FYI: I have been refactoring and renaming stuff to make the API more intuitive and to better separate the custom rules from the engine itself.

You can comment directly on the wiki page at the bottom on in comments.

http://www.tickzoom.org/wiki/TickZoomApi

NOTE: The admin is working on moving the navigation bar to the left side. Just ignore the weird layout for now, please.

Sincerely,
Wayne
 
Quote from Fractals 'R Us:

Uhh... have you written to Santa? jk :)

Open source projects are sort of known for lists of unattended to issues. You have to go commercial. Accept donations, charge, maybe not for the core but for add-ons, strategies, etc... or get some grant money.

I think this was mentioned before... offer a core version that has some functionality and demonstrates the speed and if people like it they will pay [a good bit probably] for charting add-ons, indicators, strategies, etc... or allow free use of everything but charge to allow connection to a brokerage as does Ninjatrader.

One thing that I don't like about Ninja is that it has to check it's license server before I can trade with it... that runs counter to my security measures, I have a whitelisting firewall, the less url's I allow the more secure I am. I don't want my intellectual property stolen.
More...

Thanks for all these tips!.

Wayne
 
Quote from ML_QUANT:

I have studied and tried EL, OQ and now actually using NT. Your Open Source IS what has been missing with all of them!
I wish you all the luck in the world your undertaking is humongous and hope others would step in to help too.
Maybe eventually add taking on your site might generate some income too.
As for the size of data bases, I am presently writing live tick data to txt files, one for each day/symbol and then using low level functions to read just the freshly added data using a timer! Not the fastest in the world but saves a ton of memory and can record files as large as the HDD available!
Your Vid. is very nicely done and WMP didn't open it then I used VLC, which is free and it was just fine no glitches.
Looking forward to your source and future Vid. clips.
More...

Thanks for your kind words too.

Wayne
 
Quote from ML_QUANT:

The Zenfire feed is very quickly becoming the feed of choice for the serious advanced traders due fast and unfiltered data.
I also use IB which is fine as a secondary source but definitely not a Primary.
More...

TickZoom so far only collects data from the same broker as for the trading. So it's only MB and uses MB quotes.

I have mine running on a server 24/7 and collects so it also provides back fill data whenever the black box server needs to connect to run.

Several have asked about a backup data source like Zenfire or eSignal.

But why do we need that if the broker signal goes down temporarily, we can't trade anyway, right?

Oh, but I guess the backup could avoid any gaps on the chart so when it reconnects the system already knows what's going to quickly sideline or not.

Thoughts?

Wayne
 
Quote from greaterreturn:

TickZoom so far only collects data from the same broker as for the trading. So it's only MB and uses MB quotes.

I have mine running on a server 24/7 and collects so it also provides back fill data whenever the black box server needs to connect to run.

Several have asked about a backup data source like Zenfire or eSignal.

But why do we need that if the broker signal goes down temporarily, we can't trade anyway, right?

Oh, but I guess the backup could avoid any gaps on the chart so when it reconnects the system already knows what's going to quickly sideline or not.

Thoughts?

Wayne
More...
Well, you're right on avoiding gaps on the charts but most importantly those of us using Zen are interested in fast unfiltered data! I think only Zen provides that?
So I use Zen to place orders to any of my 5 brokers and don't even know what their quote is at the time I place the orders!
Your API is built around speed and Tick data so filtered tick is not tick data anymore although mind you filtered tick could be faster in busy periods.
Anyhow since the API is open source and in C# we should then be able to easily tweak it to accept any feed I guess or not?
If not, it would be very helpful to provide provisions to make it easy for the API to ignore it's internal data source and alternatively accept data from some sort of Global memory! Like as in even the TS GV can be used to send it data etc.
Anyhow without any knowledge of the source I cannot recommend anything useful yet.
 
Quote from greaterreturn:

TickZoom so far only collects data from the same broker as for the trading. So it's only MB and uses MB quotes.

I have mine running on a server 24/7 and collects so it also provides back fill data whenever the black box server needs to connect to run.

Several have asked about a backup data source like Zenfire or eSignal.

But why do we need that if the broker signal goes down temporarily, we can't trade anyway, right?

Oh, but I guess the backup could avoid any gaps on the chart so when it reconnects the system already knows what's going to quickly sideline or not.

Thoughts?

Wayne
More...
Hi
I think the best way to handle all the different providers could be done by presenting an interface. This way it should be fairly easy to program the provider class. If a provider by any reason changes the way they push/pull data, the user of TickZoom only needs to download/ develop the provider class, instead of waiting for a TickZoom patch/ update.

I know RightEdge handles it that way :)
 
I can't login to your wiki so I'm posting here.

Backward compatibility can be a real albatross as the code grows. Maybe you could ensure backward compatibility by supporting all versions. If something is done to break the backward compatability the user can use the older versions until they fix their code to be newly compatible.

Interactive Brokers does not do backward compatibility, they break things with their new releases of the API. I guess they work with the main vendors that are using it, not sure about that..
 
Quote from ML_QUANT:

Well, you're right on avoiding gaps on the charts but most importantly those of us using Zen are interested in fast unfiltered data! I think only Zen provides that?
So I use Zen to place orders to any of my 5 brokers and don't even know what their quote is at the time I place the orders!
Your API is built around speed and Tick data so filtered tick is not tick data anymore although mind you filtered tick could be faster in busy periods.
Anyhow since the API is open source and in C# we should then be able to easily tweak it to accept any feed I guess or not?
If not, it would be very helpful to provide provisions to make it easy for the API to ignore it's internal data source and alternatively accept data from some sort of Global memory! Like as in even the TS GV can be used to send it data etc.
Anyhow without any knowledge of the source I cannot recommend anything useful yet.
More...

NOTE: This might be only for techies.

Currently, the TickZOOM engine gets fed ticks via the TickQueue.

The TickQueue a very high speed multithreaded queue. In other words, more than one thread can feed to it at the same time.

Right now, I have a BrokerSignalProxy and BrokerSignalStub class which connect via TCP/IP socket between the execution/quote server and the order server (or the PC if you're running under the GUI).

So it will be very easy to feed more ticks into the tickEngine.

We can add a value into the tick to identify feed source. Just a number (ushort).

So if you have 2 tick sources, one can just leave that field the default of zero.

The other can give the field a value of 1.

That way the engine can differentiate.

Now, here's the real question, what's the algorithm for the TickZOOM engine to decide which of those 2 feeds to use?

NOTE: We could eventually make the historical tester also able to load and feed 2 files for testing purposes.

My guess is that the software assume a backup in order of the number.

So as long as ticks feed through 0 fine, it uses those. But if those pause and starts using ticks from the backup till ticks startup again from the primary.

Thoughts?

Sincerely,
Wayne
 
Quote from janus007:

Hi
I think the best way to handle all the different providers could be done by presenting an interface. This way it should be fairly easy to program the provider class. If a provider by any reason changes the way they push/pull data, the user of TickZoom only needs to download/ develop the provider class, instead of waiting for a TickZoom patch/ update.

I know RightEdge handles it that way :)
More...

True. And that is already possible right now and how it works.

See my previous post about the TickQueue.

In FACT, instead of building that into the engine. Another might put a component called an "aggregator" in front of the engine.

The aggregator can do the logic I just talked about of deciding when to switch feeds and then only send a single tick source through to the engine.

NOTE: I recommend doing this on a symbol by symbol basis. In other words, the feed might be working for symbol A from provider 0 but failing from symbol B. So the aggregator should switch over to provider 1 for symbol B only as long as it still receives for symbol A.

Anyway, it will be possible for someone else to create an aggregator. That logic isn't too complicated and I can help will a little pseudocode probably.

In fact, that may be the best design overall to separate that from the engine.

But then again, performance will be lost by going through the TickQueue twice due to the thread locking.

So someone should add this logic into the "kernel". That's what I call the central core which loops on reading ticks, creating bars, and signaling formulas to take action.

Remember, TickZOOM has has to do a number of things that go agains standard OO or component architecture for speed. Certain things like virtual methods, delegates, can KILL performance DEAD if used in the wrong spot of code.

Your aggregator will easily become a bottle neck.

Wayne

Wayne
 
Status
Not open for further replies.
Back
Top