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)
Speeding up NinjaTrader with a RAM drive (ramdisk)
The db file that contains the databases and historical data files is MyDocuments\Ninjatrader7\db. It is not in the Program Files directory. Almost all of the stuff in the program files directorygets loaded into RAM anyway, so does not need to be on the RAM disk. (I think if you are running Ninja64, the database that is in that area is the one that is used, so I put that one on the RAM disk too. But I am running 32 due to TT data feed.)
I am about to reboot after running Advanced System Care and will update this post after knowing if the link survived. The reason I suspected a file name character issue was that there was no problem with the Ninjatrader.sdf file.
Okay, here are the results. After one restart of Ninjatrader, a run of Advanced System Care including shortcut fix, a reboot, and a second restart of Ninjatrader, all of the symbolic links including the one to Ninjatrder_Old are still there. I will continue to monitor this but it looks good for now.
The Ninjatrader db folder is on the left, the RAM Disk db folder on the right, and the Symbolic Link Target page below.
"If we don't loosen up some money, this sucker is going down." -GW Bush, 2008
“Lack of proof that something is true does not prove that it is not true - when you want to believe.” -Humpty Dumpty, 2014
“The greatest shortcoming of the human race is our inability to understand the exponential function.” Prof. Albert Bartlett
Can you help answer these questions from other members on NexusFi?
Yes of course, that was just a type-o on my part. I've set it up under Documents\ so that the entire NinjaTrader 7 folder is symlinked the the ram drive.
Imho this is the only sensible reason to use one. Have bookmarked the product just in case, thanks for posting.
Otherwise if using a 64bit OS and 64 bit Ninja I can't see why you would need one, its going to fight the page fault layer mechanisms anyway.
I am puzzled that people may be missing the real elephant in the room - simply using too much data.
I run an old 32bit Vista Dell 4Gb 4 core Q8200 @ 2.33GHz and a newish 64bit Windows7 Compaq 8Gb 8 core i7 2600 @3.4GHz, the latter is still limited to 32bit Ninja anyway owing to the only NT supported 32bit eSignal DM link.
Both systems fly, even with lots of active workspaces and charts, with sub-second workspace switch times (Shift F3.)
At the end of each day on both systems I actually delete the entire 'cache', 'data', 'day', 'minute' and 'tick' folders out of '.../Documents/NinjaTrader 7/db' and then do really fast manual backup copies of the whole '.../Documents/NinjaTrader 7' folder to USB sticks/network machine/external drive/whatever. I much prefer this to the in-built Ninja backup mechanism.
Each morning I boot both machines, open all workspaces with full historical data reload from server all done in 10 minutes and good to run for 14 hours. Seems like a good deal to me!
If folks are interested I could put together a more generic performance post but as a relative newbie on futures.io (formerly BMT) I don't yet know what's already been covered or if I'm just weird.
Actually I do know the last bit.
As @Big Mike pointed out, my linking from the db folder to individual files within a db folder on the RAM Disk did not make any sense. And eventually, the link to Ninjatrader.Old.sdf DID break again.
Now I have one link, from a junction called db in the Ninjatrader folder to a persistent virtual folder called db on the RAM disk.
Soon after installation I had serious problems with the DataRam RAM disk. Now I am using the SoftPerfect RAM Disk.
The preceding post raises some interesting points that I do not have the answers to. I AM saving chart data to historical so having the historical data stored locally on RAM should allow faster loading than having to retrieve data from a server. One thing I am sure of is that replay performance is tremendously improved with the RAM Disk, but I have not been using replay lately.
I have two PCI-E ATI Radeon dual head HD4550 graphics cards. I don't know where low end graphics become TOO low end and degrade performance. I have slow chart loading and chart freeze during fast markets and at the closing bell.
I have not seen anything on the Ninjatrader forums about improving performance with better graphics cards, but in the chatbox today it was suggested that an Nvidia card would work much better. Anyone?
"If we don't loosen up some money, this sucker is going down." -GW Bush, 2008
“Lack of proof that something is true does not prove that it is not true - when you want to believe.” -Humpty Dumpty, 2014
“The greatest shortcoming of the human race is our inability to understand the exponential function.” Prof. Albert Bartlett
For the record, I am using the Primo Professional Edition. It was cheap and license includes use for two computers, which worked well for me because I wanted to speed up my XBMC media server library.
THANKS to everyone who's contributed to this thread. I just loaded the Primo trial version and moved the GomFolder and Ninja Documents folder to my new RamDisk and replay is significantly faster. I'm also surprised more people are not following this thread.
thanks again.
Travis
I have an even more odd cornucopia of low-endish video cards (see screenshot). I do not believe chart freeze of the type you describe has anything to do with video card capability, since, the video card simply splashes onto your screen what is handed off to it's graphics/drawing engine/routines; by comparison, there is much else we can think of as examples that gives greater quantitative amounts of drawing, that I am certain your/our video cards can handle.
In a fast moving market, I too will get chart freeze, but, only in CL it seems. I find it incredibly disconcerting. I trade oil predominantly, and I believe it is due in part to the number of ticks coming into NT7 at the time, which NT7 has to process, but only because of the large amount of indicators loaded up on those CL charts.
Here's why I say this. I have many CL charts up at a time: a 60m, 25m, 15m, 800 tick, 7 renko, a OneLDOM chart, a 5M GOM ladder chart, @vvhg 's Aggregated T&S chart, and my all important 1M CL chart. There is an almost obscene amount of indicators on my 1M and 3M charts; they are my primary 'workhorse' charts. And, when a big move starts (ie., larger quantity buys/sells printing in GOM), I can feel things 'slowing down' for me. If an even bigger 'burst' move happens (ie., a GOM 5M bar goes from 400 sells to 1000+ sells), that makes things chug for me even more.
I expect that my large amount of indicators, when they all as a symphony are called upon at the same time, are chewing up CPU cycles to do the math and whatever they need to do. The fact that I have my volume indicators set to False for CalculateOnBarClose (on almost all charts), I am certain costs me dearly. (I set it this way because I want and need to see the volume getting drawn and updated in real-time, and not after the what-ever-timeframe-chart bar is closed.)
In contrast, I have noticed when I start up a almost indicator-less NT7 system on another machine (usually when NT7 decides to crash for no apparent reason as I have crucial trades in limbo), that almost indicator-free NT7, runs much more quickly, briskly, and more 'solidly' than my full-blown 40+ chart 8-monitor system, yet that backup system too runs with a plain-jane ancient 8400GS PCI (straight old-school PCI) 2-monitor solution, with a far slower CPU.
Also, while I have at least 5+ various charts of ES running, even though we know the tick throughput there is far greater, when there is a ES data burst, I do not experience chart freeze. Per chart and collectively, there are nowhere near the same number of indicators as there are amongst my CL charts.
My main 8-monitor system is currently a AMD X4 965. Being fairly certain that the loaded up CL indicators are my problem, my plan was to step up to at least a Intel 3770K solution, which should help with all the behind-the-scenes math going on, on my myriad of CL charts.
@Zondor, Hope some of that process of elimination that I think I've discovered, perhaps helps you too. In brief, I cannot think of any conceivable reason why NVidia would be any better or worse than any other video card, as NT's video card needs are very 2D, and very basic.
P.S. In fact, I have some major issues with nvlddmkm.sys BSODs; the forums are full of users of their new and old products having TONS of issues with this, and frankly, NVidia don't give a rat's ass about most of them. I have learned to 'control' the crashes, knowing what I can and cannot do. BTW, the exact same hardware, cards and configuration ran flawlessly on WinXP, but my move to Win7 introduced these BSODs, thus, I know it is not a hardware issue.
In my opinion, virtually non-existent chance video has anything to do with "freezes" during high volume activity. It's usually a poorly coded indicator, or just an old CPU.
A 3770k will be at minimum twice as fast as your AMD X4 965. Potentially much more, if you overclock. I am running a 2700k overclocked to 5ghz on water, it's 100% rock solid stable. I often run long backtests @ 100% CPU overnight.
