Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
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.
Hmm oops, math a bit wrong. Total read 16.5GB but cached read just under 4GB, so it means since boot I've 16GB from disk, but after the initial read was performed, only 4GB has been re-read and thus was delivered from the cache. So 8GB is plenty for my daily needs looks like, could even get by with less.
I think this is mainly attributed to Sierra Chart, because the data is roughly 50GB but they store it compressed (NTFS compressed) on disk, at about 18GB total. This is why on startup it balloons to 20GB of memory usage, due to Windows decompressing the data stream as it builds my charts. And since I usually only start Sierra Chart once every month or two (about as often as I reboot) then there is no real "caching", because it has to read it from disk once anyway to feed it to the cache, and I don't re-read it because I don't ever restart Sierra.
Your particular applications/daily use could be different.
Thanks for the thread! I've been wondering what I could do to help speed things up with NT-7. I am running Win-7 Pro & have 32gb of RAM. Thinking of buying the latest extreme chip from Intel & up the RAM to 64.
I run about 140 charts imbedded into one chart for two different markets.
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
Any feedback and help on this is highly appreciated.
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.
just on this description page alone, this one, might actually be worth paying for, what with all the additional features that accompany the actual allocation and maintenance of the virtual ram disk
I have a notebook with a SSD as the primary disk and a SD for some extra storage. Would it make sense to move the GOMFOLDER and NT db to the SD in order to save wear and tear on the SSD? And would it possibly make some difference to NT getting a bit sluggish in high volume bursts?