It would be great if one of the next releases of MC, we could calculate and process time not only in seconds with TIME_S but also in milliseconds.
I ask this because today, in many markets High Frequency trading systems works to hide Big traders or Big positions and today much more than yesterday a good data feed with a good granularity of data send make the difference.
Price is motivated by volume, not time. The granularity of an optimal data feed is determined by units of trade and not units of time.
While I do believe that a 1 second bar chart would indeed reflect much of this same information, much would be lost by having any measure of time as the structure constant rather than units of trade. Take this example; In the emini S&P, which until very recently has traded an average of something over 2Milion contracts during the session, if you plot this data in a 25 contract bar which generates something just short of 100,000 bars per session. A 1 second chart would only generate 24,300 during the standard 405 minute day session and their rate of presentation would be constant rather than accelerating and slowing down consistant with the rate of trade at the moment. Time as a constant with regard to this kind of processing in seconds fails to report many very pertinent facts with regard to the balance and flow of trade and money in any market.
With a slicing time not only in seconds, but in milliseconds or so, you can create many indicators like intraday intensity, volume acceleration and book intensity, so you could be more close to Big traders and their strategies.
It's a suggestion that would be very appreciate.
CraZy
Suggestion for next release about milliseconds
- CrazyNasdaq
- Posts: 321
- Joined: 02 Sep 2009
- Location: ITALY
- Has thanked: 98 times
- Been thanked: 89 times
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
- CrazyNasdaq
- Posts: 321
- Joined: 02 Sep 2009
- Location: ITALY
- Has thanked: 98 times
- Been thanked: 89 times
Well Zen-Fire is very good in my opinion and probably for my knowledge even open & Cry data is good and with good granularity. Surely not Interactive Brokers which collect data and join them in blocks of seconds.Dear CrazyNasdaq,
Which retail datafeeds do you suggest with such a granularity?today much more than yesterday a good data feed with a good granularity of data send make the difference
Zen-fire surely the best for retail customers.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
- RobotMan
- Posts: 375
- Joined: 12 Jul 2006
- Location: Los Altos, California, USA
- Has thanked: 31 times
- Been thanked: 13 times
- Contact:
I would be very interested in any practical applicability of data parsed into .001 seconds (sub-one second bars) in any retail software application. I mean, just the latency of your internet connection to the exchange data, alone, is sometimes 100 times that on a good day. Unless you are set up in a building next door to an exchange data center, running custom algorithmic / order entry software, there is really no way to take advantage of it. Other than the fact you (or your program) might be able to look at it historically. In fact the data you see in your charts is different than the order entry engine of Zen-Fire. Zen-Fire "data" is no different than eSignal or OEC as far as your charting software reading the ticks are concerned. Try this out: Try placing market or limit orders using Zen-Fire in a fast market and you will be surprised that they are filled where your charts say the market has not even traded yet. How can this be? It is the reality of how things really work, not how they work on paper.
I use Zen-Fire in NT and it surely is a fast sub-second order entry engine, however, I have the charts only update every .200 seconds and most of the time NT comes with a default setting of .500 seconds. But, I have no charts set up with bars that would take less than a second to form in either MC or NT. In fact, I mostly use 5000 volume bars on the ES (and I am a discretionary trader, so you might not think that my logic holds). This does not hamper the order entry engine in any way. Just keeps the CPU from overheating. So I would be very sincerely interested in finding out how a retail trader, like myself, using retail software, like MultiCharts, with a retail data provider like eSignal, could facilitate using sub-second bars in an automatic trading system using Zen-Fire order entry and how they would be superior to one second or longer bars trading from a home or office over commercial high speed cable internet. Just curious.
I use Zen-Fire in NT and it surely is a fast sub-second order entry engine, however, I have the charts only update every .200 seconds and most of the time NT comes with a default setting of .500 seconds. But, I have no charts set up with bars that would take less than a second to form in either MC or NT. In fact, I mostly use 5000 volume bars on the ES (and I am a discretionary trader, so you might not think that my logic holds). This does not hamper the order entry engine in any way. Just keeps the CPU from overheating. So I would be very sincerely interested in finding out how a retail trader, like myself, using retail software, like MultiCharts, with a retail data provider like eSignal, could facilitate using sub-second bars in an automatic trading system using Zen-Fire order entry and how they would be superior to one second or longer bars trading from a home or office over commercial high speed cable internet. Just curious.
- CrazyNasdaq
- Posts: 321
- Joined: 02 Sep 2009
- Location: ITALY
- Has thanked: 98 times
- Been thanked: 89 times
ALL what you write Robot, is true and right......internet connection, latency, real time order execution, latency in charting real time quotes ecc......I would be very interested in any practical applicability of data parsed into .001 seconds (sub-one second bars) in any retail software application. I mean, just the latency of your internet connection to the exchange data, alone, is sometimes 100 times that on a good day. Unless you are set up in a building next door to an exchange data center, running custom algorithmic / order entry software, there is really no way to take advantage of it. Other than the fact you (or your program) might be able to look at it historically. In fact the data you see in your charts is different than the order entry engine of Zen-Fire. Zen-Fire "data" is no different than eSignal or OEC as far as your charting software reading the ticks are concerned. Try this out: Try placing market or limit orders using Zen-Fire in a fast market and you will be surprised that they are filled where your charts say the market has not even traded yet. How can this be? It is the reality of how things really work, not how they work on paper.
I use Zen-Fire in NT and it surely is a fast sub-second order entry engine, however, I have the charts only update every .200 seconds and most of the time NT comes with a default setting of .500 seconds. But, I have no charts set up with bars that would take less than a second to form in either MC or NT. In fact, I mostly use 5000 volume bars on the ES (and I am a discretionary trader, so you might not think that my logic holds). This does not hamper the order entry engine in any way. Just keeps the CPU from overheating. So I would be very sincerely interested in finding out how a retail trader, like myself, using retail software, like MultiCharts, with a retail data provider like eSignal, could facilitate using sub-second bars in an automatic trading system using Zen-Fire order entry and how they would be superior to one second or longer bars trading from a home or office over commercial high speed cable internet. Just curious.
But with a sub-one second time calculation You colud consider one aspect that only very few people today consider......the Frequency, and those people are the ones which make the difference.
Take this example....an intraday tick by tick of ESU9 on September the 10th.
At 2.13.58 seconds A.M. (US Esat coast time - 8.13.58 a.m Italian Time) ES trades 205 times in only 1 second at price from 1038 to 1038.75 (3 ticks movment in only 1 second)....differents orders each one with different volume (Zen-Fire data feed)(120 times OEC data Feed same Future, same date, same time, instead of 205 times Zen-Fire data feed). Total volume passed in that second ....1850 contracts.
If you consider only volume, you have 1850 contracts in just 1 second and for many people it's enough, but if you consider frequency, you have the same 1850 contracts in 1 second, plus 205 trades in that second that is frequency.
Well, today Big money choose to use this high frequency trading to hide their will because new technology and internet retail trading in the last years make the difference from yesterday in their trading activity.
They use HFT (High Frequency Trading) because of they need to hide their will and themselves. If not, they won't use HFT and they wouldn't need to hide. So today frequency is the new variable to add to the market analysis as yesterday was tick data instead of minute time data or before end of day data. Trading has evolved during theses years from daily data to intraday data, from Market Profile based on 30 minutes data to Volume profile based on 1 tick data. HFT is the new weapon of Big Money traders and it's based on Frequency, and to analyze frequency you need the most precision in tools, specially in time analysis.
Then with sure, if you analyze these situations you will not be able to act in the same time then Big Money act, but you can have more information to analyze the market and to decide. When these situations happend (about 10 -20 times a day or more) the market moves very frequently in about few minutes in the opposite direction where it cames from because usually these HFT situations sign spikes and reverse, not always, but frequently and so you can act in the same new direction of the market.
If Big Money want to stop a directional movment and reverse it and place a very large single order, all the people see that order as it wolud have a flashing on it, but if they slice this order in many little orders the falshing is not visible and it's hard to decode their will. Frequency in my opinion is the answer to these new situations, and measuring frequancy in sub-one second parts is easier.
This is my opinion.
Attached you can find a picture of a rudimental tool that measure intraday frequency. Watch how peaks in intraday frequency sign market reversal.
It would be easier and more accurate with milliseconds time calculation.[/img]
- Attachments
-
- Bozza Intraday Intensity 1.png
- (44.27 KiB) Downloaded 988 times
Millisecond data resolution
I think that millisecond data resolution would be good and definitely would be a standout feature for Multicharts. However, I think you need to pare it with a complimentary set of powerlanguage display drawing tools that operate by Barnumber rather than time and date. Life would be so much easier and there would be no mispositioning of drawing tools.
J~
J~
- CrazyNasdaq
- Posts: 321
- Joined: 02 Sep 2009
- Location: ITALY
- Has thanked: 98 times
- Been thanked: 89 times
This is a similarity on what I mean about High Frequency.........FirepowerSo I would be very sincerely interested in finding out how a retail trader, like myself, using retail software, like MultiCharts, with a retail data provider like eSignal, could facilitate using sub-second bars in an automatic trading system using Zen-Fire order entry and how they would be superior to one second or longer bars trading from a home or office over commercial high speed cable internet. Just curious.
www.youtube.com/watch?v=vH5RVTS4QxA&feature=related
or again
www.youtube.com/watch?v=cP6GpAnmAPU&feature=fvw
High Frequency trading is like a Super Gatling Gun of trades in the market.......NOT always Big Bombs reach the target and destry it as many little bullets shot with High Frequency.
CraZyNasDaq
Re: Millisecond data resolution
[quote]I think that millisecond data resolution would be good and definitely would be a standout feature for Multicharts. However, I think you need to pare it with a complimentary set of powerlanguage display drawing tools that operate by Barnumber rather than time and date. Life would be so much easier and there would be no mispositioning of drawing tools. [/quote]
No matter what
resolution of time you choose you will never be able to differentiate 100 percent of the trades by time. That is why using barnumber is the best way to handle tick and volume bars with display drawing of any type.
J~
No matter what
resolution of time you choose you will never be able to differentiate 100 percent of the trades by time. That is why using barnumber is the best way to handle tick and volume bars with display drawing of any type.
J~
- arnie
- Posts: 1594
- Joined: 11 Feb 2009
- Location: Portugal
- Has thanked: 481 times
- Been thanked: 514 times
Very interesting stuff, though I'm a bit confused.
How were you able to count those 205 trades?If you consider only volume, you have 1850 contracts in just 1 second and for many people it's enough, but if you consider frequency, you have the same 1850 contracts in 1 second, plus 205 trades in that second that is frequency.
- CrazyNasdaq
- Posts: 321
- Joined: 02 Sep 2009
- Location: ITALY
- Has thanked: 98 times
- Been thanked: 89 times
Simply extracting data from Zen_fire datafeed, importing them in an excel spredsheet and processing them to identify frequency with the same second Time stamp. Then creating an indicator that count each tick with the same second time stamp and make a comparison from my indicator and Excel frequency.Very interesting stuff, though I'm a bit confused.
How were you able to count those 205 trades?If you consider only volume, you have 1850 contracts in just 1 second and for many people it's enough, but if you consider frequency, you have the same 1850 contracts in 1 second, plus 205 trades in that second that is frequency.
In the example the frequency with Zen-fire datafeed was 205 trades in the same second. The same second OEC data-feed showed 120 trades.
- RobotMan
- Posts: 375
- Joined: 12 Jul 2006
- Location: Los Altos, California, USA
- Has thanked: 31 times
- Been thanked: 13 times
- Contact:
There is a very interesting thread on the TradersLaboratory forum about this subject.
http://www.traderslaboratory.com/forums ... -5277.html
I guess this is the direction some traders are inclined to go in the granularity and frequency research to unearth the order entry profile of "the big boys". I can see how this can almost be done within MC now, except for the sub-second granularity of the data. I am not sure if this is strictly a MC issue, as each data provider would necessarily have to have their tick data indexed with sub-second time fields in order for the charting program to reference it.
I am interested only that I use volume amount and not volume frequency when I trade and look for statistically abnormal levels of upticks vs. downticks to confirm breakouts. I can see that using frequency would enable earlier detection of turning points prior to a breakout of a previous pivot.
I admit that it would be interesting to do further research in this area. However, I lack the programming skill necessary to write the .dlls required at this time to parse and file zen-fire data and then retrieve it to analyze.
http://www.traderslaboratory.com/forums ... -5277.html
I guess this is the direction some traders are inclined to go in the granularity and frequency research to unearth the order entry profile of "the big boys". I can see how this can almost be done within MC now, except for the sub-second granularity of the data. I am not sure if this is strictly a MC issue, as each data provider would necessarily have to have their tick data indexed with sub-second time fields in order for the charting program to reference it.
I am interested only that I use volume amount and not volume frequency when I trade and look for statistically abnormal levels of upticks vs. downticks to confirm breakouts. I can see that using frequency would enable earlier detection of turning points prior to a breakout of a previous pivot.
I admit that it would be interesting to do further research in this area. However, I lack the programming skill necessary to write the .dlls required at this time to parse and file zen-fire data and then retrieve it to analyze.