I've been trying out PrimoCache. Under most circumstances it makes more sense than a dedicated ramdisk, and will offer the same performance benefits.

I am using a delayed write setting of 60 seconds. I see NinjaTrader writing 50,000 blocks per minute during large backtests, so this can really help both in terms of performance as well as lifespan (SSD wear level).

I am using an 8GB cache and with my normal day to day stuff, my cache hit ratio is only around 25%. If I increased my cache size to 16GB I would have much higher ratio, as I've only read 16.4GB from disk total since my last reboot. The problem is, I need around 20GB of memory to start Sierra Chart when it is loading all my charts (once it loads them, usage is only 1GB), so the max I can safely use for the cache disk is around 8GB. I have 32GB total.

Anyway, you might try it. No need for symlink and it will work with any program, not just ones you've configured to use the ramdrive.

Naturally you should always have a backup of any important data before using something like this.

Mike

I have been experiencing freezing issues with NY using zenfire data in fast market environment.
I was told by NT support, that it is the 3rdparty indicators that are causing this issue.The developer is not totally convinced about that.
After reading the posts in this thread about using Ram disk, does it resolve those freezing issues in fast markets using zenfire?
I used to have 6 workspaces opened with all indicators when I was using IB filtered data without any issue, now with zenfire I am using a single workspace, removed most of my 3rdparty indicators, and still having issues

I am running windows 7 64 BT on 8 GB ram with Intel i7-3820 CPU @ 3.6 GHz

It definitely sounds like indicators clogging things up. I've been here, and still kind of am today. The fact that you had no issues with IB 'condensed' or 'averaged' data is the telltale sign to me. Once you introduced a feed that is completely unfiltered, sending in all ticks - which increase significantly for often many instruments at the same time - as surges in volume (both buying and selling) come through in ES, CL, other indexes, etc - is the tip off to me.

I have not yet implemented this RAM disk thingy myself for other reasons, but I do not see it helping with the issue you have, as it is to speed loading of data from the SSD/harddisk (and writing), and I don't see the rush of market ticks or bid/ask data as a write throughput issue. When that data rushes in, it's NT doing something with it, that is causing the freezes, white screens/redraws, round blue "I'm busy" Windows cursor, etc.

I'm assuming most if not all indicators are set to 'Calculate on bar close = true'. Given the indicator removals you've mentioned and the drastic reduction in workspaces - on a highly capable CPU - I wonder if recreating & replacing each chart with a new chart that contains the exact same indicators would help, and then saving that as a completely new workspace. I mention this because I have had suspicions in the past where I feel there is something else 'clogging up' the chart in it's associated template XML file. I have seen too many quirky things with NT7 charts that are part of my workspace where, for example, I'm humming along day after day for weeks or months, and then all of a sudden, some indicators disappear off my chart. I have seen this occur on multiple machines and different installs. NT7 forums have reports like this, with the answer coming back 'pack up your log and template files' and send them to us. That is of course a time killing approach that realistically few undertake since, recreating or fixing the displayed chart is the quickest action. It's possible since the XML files are getting updated, parsed, etc by NT7, that it makes a mistake. And, if it can drop indicators, it can maybe be running others we're not seeing, or, having something else sucking up valuable CPU cycles. I have over the years undertaken this, and, it has cleared things up, for a time. Often, the 'clogging' returns over time, or, other unexplained issues start occurring.

I'm not looking to gripe, but it's a huge shortcoming that @NinjaTrader does not have some sort of utility to show CPU cycles used by each chart, or, say a breakdown by indicators. Hell, it is such a robust program, and if a much smaller memory footprint program like Chrome can offer it (via SHIFT-ESC), it's really upsetting that NT cant provide us an add on utility or build it into a release update. It would offer unbelievably untold benefit to us, as, we all have vastly different indicator needs & configurations.

One thing I am quite certain of, is that based on your described circumstances, there is no way you should be seeing that type of performance hit, which, ultimately points to a NT7 flaw, or inability to coexist with something, somewhere.

I've been trying out PrimoCache. Under most circumstances it makes more sense than a dedicated ramdisk, and will offer the same performance benefits.


Mike

Robocopy is very fast if you run that frequently as a scheduled task, but it would be better to use real time synchronisation as that would reduce the loss of data to an absolute minimum. WIth real time sync, there would be no need for a slow "save on shutdown" option.

Primo Ramdisk has an option for real time replication of data to a hard drive, but I have not tested that yet. There are also products that do real time sync, such as BeyondSync and that could be used to keep a "safe" copy on a SSD. So you could create a RAM drive and use native sync with Primo or another application like BeyondSync with a freeware RAM drive.


A RAM drive can work well with NT, since that writes new data once and it read the same data many times. In addition, the amount of data written by NT and Gomi is low, so real time sync would not have an effect on performance.

If Visual Studio's performance has a bottle neck relating to the disk, you can try a RAM disk safely using Junction to point the existing directory to a replica on a RAM drive. If you don't gain a benefit, just delete the symbolic link on the C drive and restore the files from the RAM drive to the original location.

If it does give a large gain, try the Primo disk or BeyindSync or robocopy to keep a safe copy.