Inverted head and shoulders on the SPX?

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...:mad:
 
Quote from gomifromparis:
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..
More...
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 ;)

Quote from gomifromparis:

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...:mad:
More...

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
 
Quote from gomifromparis:

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 ?
More...

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.
 
TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another without duplication or losing data. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission is used to guarantee reliability of packet transfers. This fundamental technique requires the receiver to respond with an acknowledgment message as it receives the data. The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires. The timer is needed in case a packet gets lost or corrupted.
More...

TCP uses a sequence number to identify each byte of data. The sequence number identifies the order of the bytes sent from each computer so that the data can be transferred reliably and in order, regardless of any fragmentation, disordering, or packet loss that occurs during transmission. For every byte transmitted the sequence number must be incremented. In the first two steps of the 3-way handshake, both computers exchange an initial sequence number (ISN). This number can be arbitrary, and should in fact be unpredictable, in order to avoid a TCP Sequence Prediction Attack.
More...

Sequence numbers and acknowledgments cover discarding duplicate packets, retransmission of lost packets, and ordered-data transfer. To assure correctness a checksum field is included (see TCP segment structure for details on checksumming).
More...


It's the feed or NT or both; it's not the computer or the connection :)
 
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.
 
Quote from gomifromparis:

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.
More...

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.
 
You must log in or register to reply here.
Back
Top