 Posted 7/24/2009 23:09:53
|
|
|
|
You are sending ticks in the following order:
AAAA 12:00:01 Trade
AAAA 12:00:02 Trade
AAAA 12:00:03 Trade
AAAA 12:00:04 Trade
AAAA 12:01:00 Bid
BBBB 12:00:01 Trade
BBBB 12:00:02 Trade
BBBB 12:00:03 Trade
BBBB 12:00:04 Trade
BBBB 12:01:00 Bid
etc.
The problem is that the last AAAA tick is from 12:01:00. Then you send the first BBBB tick, and the time is 12:00:01. So this tick is received out of order. When RightEdge got the tick for 12:01:00, it took that as the current time, which means that the 12:00 bar would have been completed at that point for all symbols in your system. So when you get to the BBBB data it is too late to process that as part of the 12:00 bar.
Basically you want to sort the ticks by timestamp before sending them out. It may be more complicated in the real plugin, but in the code you sent us, you just need to add the following line after all the ticks have been added to the list but before calling the tickListener:
ticks.Sort(delegate(SymbolTick t1, SymbolTick t2) { return t1.tick.time.CompareTo(t2.tick.time);});
Thanks,
Daniel
|
|
|
Posted 7/26/2009 23:39:48
|
|
|
|
| Daniel, thanks for looking into this. Apparently timing among symbols is more tightly coupled in Edition 2 than Edition 1.
|
|
|
Posted 7/27/2009 11:19:58
|
|
|
|
| I'm facing some issues for the real plug-in. Thoughts appreciated by RE staff or anyone. The function that gets one minute bars, TDAC_OnOHLCBar, is triggered upon receipt of a bar for one symbol. On a large symbol list such as the S&P 500 the bars come in irregularly over a period of around 5 to 20 seconds, longer sometimes. Sometimes the timestamps are old. I am not sure that bars are generated if there are no trades. I would need to save data for each bar, and probably in a separate thread judge when bars have stopped coming in for that minute, perhaps based on receipt of data for a threshold percentage of bars plus a threshold time span of no receipt of data, and then generate ticks in the proper time sequence and send them to the listener. I might want to generate bars using last good data for symbols whose bars have not yet come in or that have bad timestamps, but not do so if the anomaly persists for more than one minute, which could indicate that the symbol has stopped trading. The reason I'm looking at one minute bars instead of streaming data in the first place is that RE gets bogged down with tick-level data on a large symbol list. Given the issues here, especially the lag in TDA one minute bar receipt, I'm starting to think that I would be better off aggregating streaming data into one minute bars myself in a separate process that talks to a RE plugin every minute. This will eliminate delays and give me better control, and also can potentially work with a variety of data feeds. From what other people have posted, it seems that aggregation in a separate process is feasible from the standpoint of CPU and other resource use. Perhaps if necessary I could run several processes on different local cores or networked machines.
|
|
|
Posted 7/27/2009 16:11:10
|
|
|
|
| Or maybe do the aggregation in RE, in a thread.
|
|
|
Posted 8/27/2009 18:57:41
|
|
|
|
| Hi steve, Aggrigation sounds like the direction but you may consider aggrigating into 10 or 15 second "slots" and then into the minute. This way you wouldn't have all the calcs happening at the end of minute... which should work better whith large symbol sets. If you want to put the aggration rules together, i.e. how you want the data combined, I can build you an "aggrator" class... Walt >> I do have interest in a TDA plug-in since they are my broker also and I have their SDK but no time (or desire to do it all)
|
|
|
Posted 10/30/2009 03:01:35
|
|
|
|
| I am working on a plugin for RE Edition2 for Russian AlfaDirect streaming data. |
I have streaming data. [28.10.2009 16:31:55] Received: *at* 651927936|12910|740|66.17|16:31:55|341598715|0|2|0 [28.10.2009 16:31:55] Received: *at* 111348438|27230|10|135830|16:31:54|341598715|6|2|0 111348439|27230|10|135810|16:31:55|341598715|1|2|1 111348440|27230|1|135815|16:31:55|341598715|6|2|1 [28.10.2009 16:31:56] Received: *at* 111348442|27230|5|135820|16:31:55|341598716|6|2|0 111348443|27230|2|135810|16:31:55|341598716|1|2|1 111348445|27230|2|135805|16:31:55|341598716|1|2|1 12910 & 27230 - it's tickets from different exchanege and I can't use ticks.Sort because 651927936 (tick number) already added.
|
|
|
Posted 10/30/2009 10:39:52
|
|
|
|
I would recommend keeping track of the most recent tick time, and if a tick comes in with a timestamp earlier than that, modify the timestamp of that tick to match the most recent one.
Daniel
|
|
|
|