I could have been clearer. I don't know anything about how efficient MQL4 is. The statement was about C++, C#, Java or anything that essentially runs native after loading. On a practical note - you want to keep the number of threads down. Don't ever do 1000 threads, at least if you're planning to run it on a Windows platform Assuming you can keep the instruction pipeline busy, one thread by core is a good starting point before adding more.
"Millisecond" is appproximately three orders of magnitude to the slow side - current tick speed is sub-microsecond.
Maybe the definition of "tick" in this case depends on the type of data feed. If you're getting full market depth (something like TotalView-ITCH), then the ticks are basically individual orders w/ instructions to add or delete from your local book. If it's just top-of-book, then that's potentially any update to the inside bid/ask price/size, as well as last trade information (ie the "ticks" would be less frequent). Even if all you really cared about was last trade data, that can still be very bursty at times and you'll probably have many occasions where multiple trades (maybe tens, hundreds[?]) take place at the exchange before you have a chance to react. Sure, you'd be able to read-in each of those trades after the fact and still maintain your processing timeline (due to buffering in the socket handler, etc)... but it's probably unrealistic to assume you'd be able to react to each and every trade <i><u>before</u></i> the next one takes place at the exchange. I'm doubting this is what you were thinking, but thought it was at least worth mentioning. Maybe put a better way, input buffering would allow you to handle bursts of ticks separated by microseconds and still keep your timeline over the long-term, but your reaction time to any given tick (ability to manage your orders) might be on the level of some number of milliseconds.
Could i have this input buffering in terms of time " certain milliseconds" and also price " certain tens of pips". This will be optimized according to the average responding (latency from input,calculation,sending order, execution) time. Is this thinking is right? or i still missing something. I hope i have a programmatic knowledge. However, i am planning to start learning Java or C#
Yes, this is what I'm trying to understand, the OP's requirements don't appear very clear. As an example, NYSE is averaging around 4 microseconds per tick in "normal" trading. It is possible to process and react at that speed, but it sure isn't going to happen with a Java or C# application sitting on top of windows. The choice of data feed is hugely important. If you're hooked up to NYSE's 10gig fiber, you're getting actual tick data. If you're hooked up to a slower feed, the ticks you're seeing are aggregated, at a minimum temporally, as multiple messages will be wrapped in a single packet. IMO this discussion Is starting at the wrong end of the donkey - the very first step needs to be to choose and fully understand the actual data feed - because that will drive everything else.
For now i am trying to trade forex via an ECN like Dukascopy. http://www.dukascopy.com/ They told me that the responding average time to execute will be around 200ms. This is for now.. My plan is to migrate later to custom java trading ATS having my trading logic and connected to Dukascopy server through their API. However, later on, if things goes well, who know what next..
Oh. I would be very very careful about drawing any deep and meaningful conclusions from tick data from such a source - that's a segregated market and you are not going to be seeing actual tick data from the broader market. More concerning than being incomplete, it will be aggregated. However, that doesn't mean it can't be a useful place to start and Learn Much about the process of building ATS! Good luck!
I wish i have the technical and financial capabilities to enter the arena of the " actual real time tick data" with HFT. Once,i go this direction, i will re contact you.. I believe i could learn from you in this regard. Thanks McGene