No or incorrect display of drawdown in V12
- This topic has 133 replies, 10 voices, and was last updated 4 months ago by
.
-
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.
1 user thanked author for this post.
Hello everyone !
I was able to run numerous backtests today without noticing a single error, as if the problem no longer existed. Is this really true? I want to believe it but I would like to be sure… Anything new on your side?
Gabriel
1 user thanked author for this post.
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 ?
It’s buried in the tech report aside the date you mentioned GraHal.
Version : v12.0.20240418030013
I could be wrong but the date pushed out under ‘about’ (21- May 2024) is a sanitised version of the build dated as timestamped above. Gone from ED (early development in APR) to (GD in MAY) general deployment or words to that effect.
Unfortunately there’s periods of ‘awkwardness’ as fixes are rolled in and I’m still trying to ferret out a reasonable DR process fallback for a family member while I’m off fishing!
We had gaps in data this week and what a football player would call general soreness from what I could only say was weird data flows – this was an eyeopener and occurred at the time you saw erratic order housekeeping this week – even with orders and systems running server side it put the wind up me (again lol) as I was trying to access and run some code on PRT servers. Many things came to mind form PeterSt’s comments on padded data to connectivity interop PRT/IG or even our transmission path to the servers because that’s been an ongoing issue but it wasn’t till the other thread was posted this week that it all came together –
A list of interop ‘features’ would be handy for us newbs!
Anyhow thanks for pointing out the new rev. and it’s ‘last update’ does marry with a bit of chaos this week, so perhaps break fixes in play.
To anyone with the power to make it happen.
Public facing – Release Notes – would be really really handy, please … 🙂
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.
Well, it seems that I was optimistic in my previous post, the problem persists and perhaps it is even more serious than described before.
I just performed some script optimization. At the end of the process, the script automatically launches a calculation using the parameters from the first line of the report (see pic) and differences appeared between this optimization report (line 1) and the detailed report:
1480 versus 1616
74 versus 80.80
708 versus 684
1930 versus 2042
What does all this mean and how can we trust this type of analysis ?
I don’t really know what to think about it.
Gabriel
1 user thanked author for this post.
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.
1 user thanked author for this post.
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 🙂
Find exclusive trading pro-tools on 
