Test Report - 2020-12-08

[jmscraig]

Morning.

I see you made a good size commit with lots of changes so these test results are not reflective of the current code.

Ran four clients overnight, all unmodified code. 2 PriceReversal, to MACrossover

All four visually appear to be still running but charts on the VPS are stuck at 12:45am on the Dev machine they are both stuck at 12:47am.

Overnight the VPS had no other strategies or charts running.

All other charts on the Dev machine (18 charts heavily loaded with indicators and a some strategies) ran perfectly and are showing correct times.

I will pull down the commits and put that up for a test.

Config of PriceReversal

Config of the MACrossover

[MicroTrendsTom]

Evening ;-)

Ty for your awesome report and efforts. "All four visually appear to be still running but charts on the VPS are stuck at 12:45am on the Dev machine they are both stuck at 12:47am." ah ok not so awesome i did see some locking issues with locks put in and decided to remove locks that were contextually safe to do so - for simple fast actions where there was not enumeration of a list with a possible change etc

it does also strike me that it may indeed work better off chart as an invisible strategy - charts are slow and we often see GUI thread issues with deadlocks etc - but the aim is to get it working good enough on all etc of course.

[jmscraig]

for simple fast actions where there was not enumeration of a list with a possible change etc.

In debug did you see any locking up?

may indeed work better off chart as an invisible strategy

I agree that thus far environmental factors seem to influence the reliability. Usually, strategies with lots of tracing enabled have been more reliable than when running without.

So much that it left me thinking..

• if it is reliable on an 8 tick with tracing maybe it will still be reliable on a 12 tick but for sure a 20tick.
• we can trade consider both tracing and configured cycle times as being a combined buffering solution.

[jmscraig]

From all the reading multiple threads even reading the same list with "contains" or even a .ToArray() call is like buying a lottery ticket.. best case it will happen rarely but eventual some hits

Long term I will not be surprised to see a ConcurrentDictionaries replace the use of Lists. In fact that might be a worthy investment of time over time fixing locks..

[jmscraig]

90 mins into this test ..
PriceReversal 1 second and 2 secnod running great. 100% default configs. MACross MNQ 18tick Hung and frooze the chart in 15 min (no logging or tracing enabled). MACross MNQ 8tick is running great(no logging or tracing enabled).

[jmscraig]

fyi .. .example use of ConcurrentDictionary in OnMarketData()

`

uint ui_volume ; lock (e.Instrument.SyncMarketData) { ui_volume = (uint)e.Volume ; _cdictionary.AddOrUpdate(e.Price, ui_volume, (price, oldVolume) => oldVolume + ui_volume); }

`

[jmscraig]

NT Jim posted a good example use of Concurrent dictionary more complex than replacing the lists.. Using a data Class to add multiple items per dictionary row.

https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/102909-imbalance-strategy?p=803902#post803902

That slows things down a lot and generates a lot heap GC pressure so not encouraged unless really needed but proves the ConDict is viable for far more than is needed here.

ConcurrentDictionaries 200-400% slower to load each row than a list, but provide lock like security for read with no identifiable locks or locking if your the reader.

We read so much more than we write so the ConDict might be a massive win.

[jmscraig]

making this content an enhancement post on ConDicts.

[jmscraig]

The majority of content in this issue no longer top shelf relevant so closing