Account Performance: Not quite there yet

[cgeorgan]

Guys,

This has to do with NT7B20. I've known for a while of the "quirks" of the account performance tab. Positive numbers that show up as red, negative numbers, phantom positions that re-appear after you synchronize your database, etc.

Here's an example screen shot of one instrument (6S) from today and yesterday. Attached you'll find the account performance screen, and the chart where trades have been recorded.

Clearly there's a disparity.

This system closes itself everyday at COB (4:15 CST). I personally ensure this. The program is then restarted.

As you can see from the performance manager, we've got trades that lasted from 8/13 to 8/17, 8/18 (never happened).

There are other trades that are either missing, mislabeled, or attached incorrectly.

I can personally keep track of my information...so I know, for example, that 6S today had a couple good trades and did not "lose money" as the performance tab indicated...but this sort of programmatic behavior really makes testing difficult.

PS to show I'm not crazy, I changed the history dates from 8/11-8/19 to 8/18-8/19...everything looks fine there! Can you see how this sort of thing frustrates testing?

[cgeorgan]

Actually, I learned a neat trick: If I simply change the lookback dates, I can get my daily P/L to change with it! Watch:

What I've done here is take the same data, then just walk back the dates. You can see that by merely changing the dates, the PnL changes for almost every single date. There's no way of knowing exactly what happened (actually, I know personally because I write down the info at the end of every day so that at least somebody is keeping accurate records).

Guys, what's the story here? If this is a database file, how is it that trades are being mixed up? Are there no unique/master trade keys that keeps things in order???

[NinjaTrader_RyanM1]

Hello cgeorgan,

Thank you for the report.

Can you plase mail us your database file? You can find this at;
My Documents\NinjaTrader 7\db\NinjaTrader.sdf

Also include your trace and log files for all days that these orders were placed. May be easier to zip up all of them.

Send to [email protected] and reference this thread:

http://www.ninjatrader.com/support/forum/showthread.php?t=32674

We'll attempt to reproduce what you're seeing here.

[NinjaTrader_RyanM1]

Thanks for the files. We are looking into this and will reply tomorrow.

[cgeorgan]

Thanks for the files. We are looking into this and will reply tomorrow.

I know for certain that this is a result of - at a minimum - the symbol GC, and possibly SI & HG.

Due to a bug I've been talking about to you guys for a while (whereby a bid of "zero" will trigger executions of target orders for short positions, resulting in a fill of "zero" which cannot be removed), I have been forced to add "filler" transactions that replicate an actual position.

For example, if I was short 3 GC @ 1228, the bug will inevitably (happens 70-90% of the time) cause a fill of "zero", which results in something like $980,000 in profits. To reverse this, I insert trades that essentially sell 3 GC @ 0.001, then buy to cover 3 @ 1228. I then insert a new position of short 3 GC @ 1228, and wait to insert a closing trade based on where GC trades later.

Thus, I've thoroughly confused NinjaTrader, though it allows me to at least test these 3 instruments. If you remove GC, HG and SI fills, then you won't get the problem I've described to you.

[NinjaTrader_RyanM1]

Thanks for your analysis so far. Yes, can definnitely lead to issues if the execution price is zero and this is a good place to start for the performance reporting issues you're seeing.

Can you let us know the thread you posted or the ticket # so we can look into this case you mentioned?

[billr]

I am replying to this thread because I have also seen some suspect performance results and phantom trades on the charts. Is there an issue with the backtesting performance functions that we should be aware of? cgeorgans case is worrisome.

Thanks.

[NinjaTrader_RyanM1]

billr,

There are no known issues and we're trying to isolate what's happing in this case.

Let us know if you have any additional information that will be helpful in tracking this down.

[cgeorgan]

Thanks for your analysis so far. Yes, can definnitely lead to issues if the execution price is zero and this is a good place to start for the performance reporting issues you're seeing.

Can you let us know the thread you posted or the ticket # so we can look into this case you mentioned?

There is 336244, with Brett/Josh, that dealt with removing zero-fill executions;

There is also 334665, which I think might also be associated with this problem.

I can say now that I'm having spillover - if such a thing is possible - from this problem into NQ and 6C executions. I've never had a problem with those two instruments, but I can confirm to myself that the tracking of these two instruments has become corrupted (despite a "Repair DB" attempt), resulting in account performances that are far from what actually happened.

PS The answer to this question cannot be "reset the database"...there has to be a solution out there.

[NinjaTrader_Bertrand]

cgeorgan, thanks for the patience and reporting this in to us.

When you DB file is really corrupted, there's unfortunately no real alternative to a reset.

However we would for sure be interested how you're getting into this state, for this we would need to work out a reproducible scenario so we can track the issue down to it's core.

To clarify what I've understood so far: the 0 execution and you subsequently adding manual executions would produce the erratic reporting you now see?

Which feed are you using here, so I can look into testing with more detail?

[cgeorgan]

cgeorgan, thanks for the patience and reporting this in to us.

When you DB file is really corrupted, there's unfortunately no real alternative to a reset.

However we would for sure be interested how you're getting into this state, for this we would need to work out a reproducible scenario so we can track the issue down to it's core.

To clarify what I've understood so far: the 0 execution and you subsequently adding manual executions would produce the erratic reporting you now see?

Which feed are you using here, so I can look into testing with more detail?

Bertrand-

I'll explain to you how to get a zero quote (I can get it almost every day). It has almost nothing to do with the automated system, and a lot more to do with DTN and order execution. Here are the following steps:

1. Use DTN-IQ for data.
2. Have an automated system (basic crossover should do) that gets you into a short position. Here, you should have a stop-market buy-to-cover order, and a matching buy-limit profitable order.
3. A bid of "0" will show up in DTN (bid, not last trade). This zero bid will cause your buy-to-cover limit target order to trigger, filling it with a price of 0.
4. This results in a full-profit trade...that is, you sold GC @ 1231, and you bought it at zero.
5. To reverse, I enter a sell order for GC @ $0.001. I then enter a buy order for 1 GC at the original entry price (say, 1231).
6. I watch GC to see when one of the two price targets (stop or profit) were hit. Then, I manually enter the trade - short @ 1231, then either out at 1220 or 1240.

This will ensure that at least I see the correct PnL but - as you can see - it creates other problems.

This works with GC, HG, SI and NG contracts.

[NinjaTrader_JoshP]

cgeorgan,

When you filter your performance report for different dates it tries to find all trades associated with the last time you were flat from the start date. If the last time you were flat goes farther up then the start date it will add those executions in. I can see potential for the manually added executions you have causing the pairing of trades to be off. Unfortunately only a thorough analysis by hand through all of your executions can this be determined. I suspect there is a manually added execution in there causing downstream pairings to go off. It is just a matter of finding where it was added.

[cgeorgan]

cgeorgan,

When you filter your performance report for different dates it tries to find all trades associated with the last time you were flat from the start date. If the last time you were flat goes farther up then the start date it will add those executions in. I can see potential for the manually added executions you have causing the pairing of trades to be off. Unfortunately only a thorough analysis by hand through all of your executions can this be determined. I suspect there is a manually added execution in there causing downstream pairings to go off. It is just a matter of finding where it was added.

I don't have a problem with that explanation. What I think I might find more difficult is getting into the DB to remedy this.

Is it possible to isolate all executions from a single instrument that have occurred since using a specified account? What do I need to manipulate the DB?

PS Is it possible that, in fact, the DB is flat to the contract in the given instrument, but that the method of order used in determining position is off? Executions are not transitive in nature -

[cgeorgan]

More instruments

I'd like to note that it seems rather easy to "break" the string of executions, resulting in incorrect positioning information. Besides GC, I've managed to do it for 6C and NQ now. Because of this, I have to move to an all new Sim account ("Sim 103"). Sim 101 and 102 have been rendered useless by similar problems.

If you're going to give people the ability to add/delete executions, you need to also provide them with a method by which they can enter the main transaction database to ensure all transactions are copacetic. Anything short of that is recipe for major problems.