OK whoops forgive me I was mistaken. Sorry; I've been corresponding with quite a few folks over the past few days and got things mixed up. (Was looking for the proof after I posted and couldn't find it.. lol). I did NOT find an IRT/eSignal discrepancy.
Thx, coding was more like using other people's work : took the indicator code of CD on the dedicated Ninja forum thread, and took the bar charting logic from ValueChart indicator on Ninja indicators section... Anyway, I set up a tick recorder, will see if I see differences using live and replay. Problem is that the "correct" chart appears on replay...
Wise, wise man. Why re-invent the wheel? All of my past indicators grew from bits & pieces of other code I found. These days, I'm doing things no one has posted so it's all from scratch but the fastest way to learn is to take what's already out there If that's the case, make sure you alert NT support. Replay should be 100% identical to live. I'd be interested in having them review the source code as well. Like I said though, you're having the exact opposite of the problem I may be experiencing... Will test this as soon as mkt closes today
Well it seems an other guy got the exact same problem : http://www.ninjatrader-support2.com/vb/showpost.php?p=38283&postcount=100 Maybe due to the event driven logic of OnMarketData : you have no guarantee ticks are dealt with in the correct order. Question is : are live calculations usable and reliable ?
interesting. Ok, I just check my connection and it looks like NT/zen is running the TCP protocol so reliability is built in. It's been a while since I studied the TCP protocol but I believe the sequencing capabilities allow for data to arrive & be assembled in the order it was sent (correct me if i'm wrong). This means whether the timestamp is correct or not, your ticks will still be constructed in the same, chronological order. Now if this is not correct, the ticks will be received regardless (unless you experience a packet drop), and merely constructed out of order on the timeframe of milliseconds to maybe seconds. Since it's all cumulative in the end, I don't believe these minor deviations should alter your view in any significant way (unless you're watching a 1 second chart). Also note the indicator posted on NT forums was incorrect at that time. We should make sure we're comparing apples to apples. I posted a snippet of the correct logic, which I believe sbgtrading has incorporated. I have not verified it. Thoughts? OK EDIT: sorry i must be having a brain lapse this morning, yes having data arrive out of order would matter because you need the correct sequencing to properly grab bid/ask/sales levels.
Sure, but the NT logic is event-oriented. Suppose you do some action in OnMarketData, and suppose the action is not complete when the next event is fired. What happens ? Events are buffered I suppose. What I'm looking into is how they are unbuffered. If there's an asynchronous process somewhere, it could cause the problem because you can't guarantee a correct unbuffering sequence.
ahh i see where you're coming from.. I would expect NT to be using a queue? Doesn't make sense they would just make it a grab bag lol remember, TCP wont deliver packets to NT out of order.. the whole OSI model thing. When it leaves layer 4, it WILL be in the correct order, and thus enter NT in the correct order
There's a serious geektalk parade going on here... lol Just to let everyone that's using I/RT know, the latest version 9.2.5 that supposedly fixes the DTN/MA tick stream problem is being recalled, use 9.2.4 I'm told. FYI.