c# Automated Trading Software created by myself

NetTecture · Feb 5, 2012

Quote from shewenhao:
Here are something I do not understand. I know we should set up priority thing in thread pool to make sure that information from tick update should not be delayed for the sick of slippage. But what do you mean " the system should be able to Close the bar without waiting for a tick to close the previous bar" I simply do not understand the english here.

It is one of those things that sounds easy but are not implementable. If you can close bar x without bar x-1 (prior) to be closed, and it gets closed later, you destroy logical cardinality. Backtesting / reproduction of results is impossible in a scenario like this.

IMHO decent software should:

* Capture, Decouple indicators / compression from logic so they can run on multiple threads. This is quite simple - one thread pulls data sends it into a queue, second thread does compression, idicators, third thread + (multiple in parallel) can run strategies, UI etc.

* Handle data delay in a gracefull manner. Gracefull means it can start crying like mad (screen flashing, log entries, closep ositions and wait for admin reaction) but it should handle it in a way that deals with this and dos not go on trading when falling behind. This should normally NOT be the case cliend side anyway - delay problems likely come from network / provider issues.

and that is about it. Getting into the area of non determinstic programming for something like traing is IMHO creating a TON more problems than it solves. Given a decent data stream, data will pour in fast and without drops, so a tick not received is neve ra tick "not yet" received, but really one never to be received. I can naturally only talk from my experience with Rithmic, NxCore etc. - i.e. professional grade high quality feeds. But even with a lot quality HTTP based feeds the feed may hang (lost TCP packet) but packets (and thus ticks) will not arrive out of order.

shewenhao · Feb 5, 2012

Quote from NetTecture:

It is one of those things that sounds easy but are not implementable. If you can close bar x without bar x-1 (prior) to be closed, and it gets closed later, you destroy logical cardinality. Backtesting / reproduction of results is impossible in a scenario like this.

IMHO decent software should:

* Capture, Decouple indicators / compression from logic so they can run on multiple threads. This is quite simple - one thread pulls data sends it into a queue, second thread does compression, idicators, third thread + (multiple in parallel) can run strategies, UI etc.

* Handle data delay in a gracefull manner. Gracefull means it can start crying like mad (screen flashing, log entries, closep ositions and wait for admin reaction) but it should handle it in a way that deals with this and dos not go on trading when falling behind. This should normally NOT be the case cliend side anyway - delay problems likely come from network / provider issues.

and that is about it. Getting into the area of non determinstic programming for something like traing is IMHO creating a TON more problems than it solves. Given a decent data stream, data will pour in fast and without drops, so a tick not received is neve ra tick "not yet" received, but really one never to be received. I can naturally only talk from my experience with Rithmic, NxCore etc. - i.e. professional grade high quality feeds. But even with a lot quality HTTP based feeds the feed may hang (lost TCP packet) but packets (and thus ticks) will not arrive out of order.

Thank you for your post for me to better understand the way we think about the software design and threading. It is so true that we should keep the logics correct behind the scene. But usually it is not a problem right? Data feed in now days is quite good, right?

NetTecture · Feb 5, 2012

Quote from shewenhao:

Thank you for your post for me to better understand the way we think about the software design and threading. It is so true that we should keep the logics correct behind the scene. But usually it is not a problem right? Data feed in now days is quite good, right?

That depends on what you use. Packet loss on the internet is not high, but it CAN make a connection stop. TCP handles lost packets by a up to 60 second "no data delivered" delay worst case.

Professional / good progviders use UDP while the connection is open, witha TCP connection in the background to pull "missing / late" pakets fast. They also measure link stability all the time etc. etc. etc.

Especially if you move data center (i.e. do not host at home) you should pretty much get only n occasional drop here and there.

The main issue is: no feed I know of will SHOW you the data out of order. They may get HUNG while the connection reestablishes, but they are not programmed to give you data out of order. This is like video streaming - you may miss a fram, but it is not going to be re-inserted at a later stage. Any out of order execution capbilities are thus totally build on a false premise.