Batty wrote:

It is the Automatically generated Detailed Report that hs the double counting issue.

AHA … above is probably why I do not / rarely see the double counting as I have the automatically generated Detailed Report disabled / turned off.

When I decide on which 1 or 2 (out of 8 to 10 backtests – different TF’s etc) I want to explore further, THEN I click on System title on the equity curve and select Detailed Report.

I guess I have inadvertently been using a ‘work around’ all along without even realising it … hence why I have not added much to this discussion.

Batty, I don’t understand what your problem is now. the solution. Just do what I advise to do in there. 🙂 Then it works fine.

There was an update to PRT on 21 May 24 so maybe the fix was in this last update.

Never understood why PRT don’t increment the version number when an update has been installed … it’s still at v12 – 17.0.7.

I would expect increment to v12 – 17.0.8   or if a minor update, v12 – 17.0.71 ?

I’m still getting instances of the double-counting.  Maybe not as frequent as before but that is difficult to say as it has always been random. I checked the update date and it says 21st May. Is anyone else who previously had this happening also still getting the same problem?

Very interesting reading past few pages.

There’s merit to where the testing lands on the backend aka dev lab or retail env., should test across retail env. as a final POC. I wonder how many of the dev team tweak there workstations. So the point about how problems are ‘reproduced’ is critical here, hopefully the systems engineers are working to a very tight retail equiv. regime.

The issue manifest when a result is spat out automatically as part of the process vs being manually derived (per GraHals comment in never seeing it (manual) vs Batty’s and other reports of it being an unresolved issue when reporting is bundled).

How is memory util. fairing through this procedure/process when back testing and pumping out a report automatically? How close to max. memory are people seeing (memory usage/free allocated to the app, not total free system ram).

(Help > technical support  > other > report details (at the bottom) blows open an app ram util graphic)

I ask because in my vanilla testing I’m allocating 16GB ram just so I don’t hit a wall and at times last week I hit it again (me thing maybe, perhaps TOD and event driven data flows as well) but yes v12 is hungry. To be fair I am doing more with it now too as a discovery process and will rollback to a sanitised setup.

Although I’ve not reached the levels of others and this isn’t related to problems others see, resource allocation could be a thing and could be the client workstation tapping out and hitting a wall.

Most will have stripped the env. back to a ‘back-test-only’ setup and are still seeing problems but the very first problem I encountered when jumping from v11 to v12 was ram resource issues and jumped from 8gb java allocation to 12 and now 16 … 😐

You can set multiples of 1024 under Windows: settings > About > Advanced systems settings > Environment Variables:

Add New

(PRT defaults to 8GB from memory) (really should be enough in a light setup as a stab in the dark).

8192

9216

10240

11264

12288 (ran this for a while on 32GB PC)

add 1024 etc

_JAVA_OPTIONS

-Xmx16384m

TBH this is overkill and why should a retail customer need to do this, so I can hear the screams already but if there’s no choice and as an interim measure it’s worth a look.

Probably barking up the wrong tree wrt to the report generation but a lack of resources shows up in the weirdest of places.

The most worrying thing to me is the lack of response on this issue from IG or PRT. I find it extraorinary.

Thanks for your notes @Inverse. Unfortunately I don’t think these tweaks at my end will fix the Detailed Reports issue. My laptop has a reasonably good spec …. Xeon processor and 32gb, When I run PRT in a context that creates the lightest load on my system (just PRT running, at the weekend when the markets are closed, and just one backtest at a time), the double-counting issue still occurs – completely randomly, at times more frequently than at other times. There is no obvious pattern to it although I think probably it is more frequent during the week when the markets are open.

I noticed today a new button on the chart menu (at least I think it is new – I have never seen it before). It is a graphic of a chart, screenshot below. Clicking this runs and opens the Detailed Report. So at least now I don’t have to open the chart menu and click from there to do this, just the one click on this button runs the report. So if you have things set to open the reports automatically, at least this speeds up the process of regenerating it if the double counting, or other errors, occur.

Strangely, the (new) Detailed Report button is only showing on one of my accounts at present, not all of them, yet the “Latest Update” dates and version numbers are the same … 21st May. v12 17.07.

15-38-30_Spot-Gold-1-5-seconds-2344.1-0.64-15_38_31.png

Batty wrote:

I noticed today a new button on the chart menu (at least I think it is new – I have never seen it before). It is a graphic of a chart, screenshot below. Clicking this runs and opens the Detailed Report. So at least now I don’t have to open the chart menu and click from there to do this, just the one click on this button runs the report. So if you have things set to open the reports automatically, at least this speeds up the process of regenerating it if the double counting, or other errors, occur. Strangely, the (new) Detailed Report button is only showing on one of my accounts at present, not all of them, yet the “Latest Update” dates and version numbers are the same … 21st May. v12 17.07.

Sorry all … I got this wrong. I realise now there is an option in the Graph menu to star the Detailed Report button as a “favourite”, in which case it appears directly on the menu bar   🙂