Support Board
Date/Time: Sun, 24 Nov 2024 01:32:13 +0000
Rithmic millisecond not working right
View Count: 2783
| [2013-08-09 12:49:52] |
| Hendrixon - Posts: 130 |
|
SC version 1007. 1. No bar has a start timestamp of over HH:MM:SS.400 (400ms) 2. Bars always have a start time which is very close to the "seconds" (__:__:SS.000) start. examples: Crude Oil 50 Volume bars = Bars start time is always less than HH:MM:SS.50 (50ms). Crude Oil 100 Volume bars = Bars start time is always less than HH:MM:SS.85 (85ms). There are two exceptions to #2: A. Either the bar's own duration is 1 second or less. B. Or the prior bar's duration is less than 1 second. Date Time Of Last Edit: 2013-08-09 12:50:38
|
File1.png| [2013-08-09 17:39:00] |
| |
|
We do know about the 400 milliseconds. Implementing millisecond support properly does take a lot of considerations and various small changes in many areas of Sierra Chart which have not been done yet. All has to be considered carefully. We had to limit this to 400 milliseconds to avoid getting close to 500 milliseconds or over which can cause problems with how time values are rounded now.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2013-08-10 14:30:14] |
| Hendrixon - Posts: 130 |
|
Understood. Any time frame when to expect the 400ms limit off? What about issue number two? It can't be that only bars with a duration of 1 second or less, have millisecond timestamps that are bigger than 50ms or 100ms? you obviously do something there as well. |
| [2013-08-13 17:46:26] |
| |
|
Full millisecond support should be ready sometime in the next couple of months. 2. The millisecond time stamping is not in regards to actual time, it acts as a counter starting at 0 to give trades unique times. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2013-08-14 10:38:05] |
| Hendrixon - Posts: 130 |
|
What??? a counter?! Now it makes sense why the bars look so strange and why you said that you are "not using Rithmic's Millisecond timestamps but your own". Unless this is just for development of the infrastructure and you're going to strap "real millisecond time parts" on it... I must say this is an enormous disappointment. first time in 2.5 years that I'm using SC :-\ Please reconsider and implement real time based millisecond timestamps. I'm literally begging you. |
| [2013-08-15 02:35:54] |
| ganz - Posts: 1048 |
|
Hendrixon hi could you explain why the "real millisecond time parts" are so important for the Charting software /not a DMA stuff/ ? ty Date Time Of Last Edit: 2013-08-15 02:37:16
|
| [2013-08-15 10:15:58] |
| Hendrixon - Posts: 130 |
|
Hey ganz For the charting software? First of all you'll finally get a good smooth "live like" replay, not the jerky "1 second bursts" replay we have now. if you'll look on a replay of 30min bars than maybe it won't bother you, but look on a numbers reversal chart and you'll see how useless it is. But more importantly, for short time frame traders and scalpers, the 1 second timestamping is a limit/problem. You can't construct short time frame bars phases to look for repeating fingerprints/formations/sequences since the granularity is too crude. For example if you have a formation that you found to work super on 30min bars (like morning star or evening star etc.), your options to find that formation are: 1. Wait for it to happen again. 2. Build bar phase charts What I mean by bar phase chart is that by default your 30min bars start forming lets say at your midnight (set in chart properties), but what if you'll start your chart at midnight+10min? Well, your charting software will sill produce 30min bars, right? but they'll have different OHLC parameters. Now if your beloved formation repeats lets say twice a day, well now you have double the odds to spot it. And if you'll have another chart that starts at midnight+20min... voila... you tripled the chance to find your formation! in the same day! Nice right? :-) So why stop at 10min granularity? Why not building bar phases every 5min? or every 1min? Go for it. But, what if your charting software has a timestamp granularity of 15min? It means you're limited to only 2 bar phases. If it had a granularity of 10min, you could build 3 phases etc. Well that's the problem at very short time frame and small tick/volume bar sizes. The 1 second timestamp granularity is pretty much like the 15min granularity above. And its worse, since if you know that the formation you found works so good on 30min bars, you know it will work pretty the same on 240min bars and 5 min bars. But with the 15min granularity you have, you can't build 5min charts, let alone 5min phase charts :-) And that's just the tip of the iceberg. Milliseconds is not just for "blackbox HFT execution", but most retails don't have a clue what to do with it. All they think is *execution*, and in that game, sure, they can't win, so they diss(?) millisecond granularity as "not needed and pretty stupid for retails". Btw, Multicharts already support microseconds. and HFT? they already execute at nanoseconds. Who knows, I work with the 1 second granularity and see the need for milliseconds. Maybe others that already worked with milliseconds found benefits in microseconds? and now nanoseconds? I'll be content for a long time if SC will add real millisecond timestamp support, which as far as I know Rithmic already support down to microsecond. Hope that helps. Date Time Of Last Edit: 2013-08-15 10:19:39
|
| [2013-08-15 12:16:55] |
| ganz - Posts: 1048 |
|
Hendrixon hi thanx for the explanation. Btw, Multicharts already support microseconds.
Multicharts is full of bugs. It is just inefficient and heavy-weight software. They are realy need to solve memory leaking with their .net components. I have no idea how MC users will use micro- ... nano-... or something else. but look on a numbers reversal chart and you'll see how useless it is.
You can't construct short time frame bars phases to look for repeating fingerprints/formations/sequences since the granularity is too crude.
As described above SC provides an under-a-seconds timefrime. SC can record ticks within a second in the right order. So you will able to do everthing you have explained. Or am I missing something? ty |
| [2013-08-15 12:50:00] |
| Hendrixon - Posts: 130 |
|
I never even tested MC since I'm fully content with SC, so have no idea how buggy or not MC is. Just stated a fact. As far as SC explained so far, they don't provide the "real" time based millisecond timestamp of every tick, the one the exchange or ticker plant provides. they simply run a counter and give a numeric ID for every new tick in a single second. so if you have 4 ticks in a second, their "timestamps" will look like this: Tick 1 = HH:MM:SS.000 Tick 2 = HH:MM:SS.001 Tick 3 = HH:MM:SS.002 Tick 4 = HH:MM:SS.003 That's even if tick 1 came 14ms into that second (HH:MM:SS.014) and tick 2 came 947ms into that second (HH:MM:SS.947) etc. You can't build phase charts out of that or do any real time analysis with that. Date Time Of Last Edit: 2013-08-15 12:51:26
|
| [2013-08-15 13:01:48] |
| ganz - Posts: 1048 |
|
Hendrixon OK. Your opinion is clear. My opinion is different: - if ticks will are in the right order within a seconds - a chart will be built correctly - if one has no plans to make a trading decision as fast as hft are - there is no reason to have the "real" time based millisecond timestamp of every tick gd lck |
| [2013-08-15 13:33:20] |
| TastyRisk - Posts: 119 |
|
I would like to see real millisecond support. IMHO; SC is losing value as the market becomes more efficient. If we can't get accurate bars then what's the use of the software? I'm spending more and more time with open office nowadays as "no charts" are better than "inaccurate charts". |
| [2013-08-16 08:54:55] |
| |
|
We don't have time to comment on everything being said here. But we do see misunderstandings and things said that do not make technical sense and are not relevant. True millisecond support is coming. It is a work in progress. We can clearly see, that there are 2 different objectives here. Sierra Chart needs to uniquely identify trades and it will use milliseconds as a counter. And also an option will be added to support the millisecond data from external services. Although what you will find with that data, is many trades occur within the same millisecond. We have observed this now with Rithmic from some testing. This would defeat one of the main reasons millisecond support is being added in Sierra Chart. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2013-08-16 08:56:40
|
| [2013-09-04 02:38:27] |
| User97332 - Posts: 1 |
|
so milliseconds chart are not working not more with iq feed too is that rigth ?
|
| [2013-09-04 02:52:36] |
| |
|
We do not use IQ Feed milliseconds at this time.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: