NinjaTrader 8 chart delays if volume increases (Page 2) - NinjaTrader | futures.io
futures.io futures trading
 

Go Back   futures.io

> Futures Trading, News, Charts and Platforms > Platforms and Indicators > NinjaTrader


NinjaTrader 8 chart delays if volume increases
Started:November 9th, 2016 (11:35 AM) by andorre Views / Replies:676 / 23
Last Reply:November 13th, 2016 (08:46 AM) Attachments:0

Welcome to futures.io.

Welcome, Guest!

This forum was established to help traders (especially futures traders) by openly sharing indicators, strategies, methods, trading journals and discussing the psychology of trading.

We are fundamentally different than most other trading forums:
  • We work extremely hard to keep things positive on our forums.
  • We do not tolerate rude behavior, trolling, or vendor advertising in posts.
  • We firmly believe in openness and encourage sharing. The holy grail is within you, it is not something tangible you can download.
  • We expect our members to participate and become a part of the community. Help yourself by helping others.


You'll need to register in order to view the content of the threads and start contributing to our community. It's free and simple, and we will never resell your private information.

-- Big Mike
     

Reply
 
Thread Tools Search this Thread

NinjaTrader 8 chart delays if volume increases

Old November 10th, 2016, 03:34 PM   #11 (permalink)
Market Wizard
Birmingham UK
 
Futures Experience: Intermediate
Platform: NinjaTrader
Broker/Data: IG/eSignal
Favorite Futures: Dax
 
ratfink's Avatar
 
Posts: 2,910 since Dec 2012
Thanks: 9,245 given, 5,659 received
Forum Reputation: Legendary


andorre View Post
Thank you!

If I decrease the number of charts and indicators, then the problem can vanish, i.e. the same what you write.
(I have only NT8 indicators.)
Yesterday after the US election there was such a huge volume that I had no chance to trade.

Would be interesting if you could confirm that there is also a maximum of 30% CPU working during heavy volume.

You see: If my whole PC (100% CPU) tries to manage the heavy volume and cannot achieve this task because
it is too old, then I am convinced of the software. But in this case one should try to solve this problem.

I would not expect to see 100% CPU usage regardless of increased multiple-threading. Moving data between threads is expensive, regardless of the mechanisms used, so that there is often way less benefit than advertised. With much object-oriented software the hardware cores will frequently be stalled in the MMUs or even worse at the page pool if you have excessive data usage (worth checking, but less likely unless you have leak conditions).

Regardless of machine and software, it will always come back to asking whether the right type of charts are being employed for the job - e.g. do you need tick level data for something that could just as easily be seen with a time based series? e.g. do you need to load 100 days when 4 would do? and so, on. Maybe you already did that.

[As a comparison I run multiple workspaces on several machines of varying ages with truckloads of charts and symbols and drawing from custom code under NT7 and average 1.5% cpu pretty much all the time - I simply choose the level of analysis that is optimum and reasonable for each visualisation I want.]

It might be useful if you gave more idea of the charts you use, the memory usage (e.g. working set size, etc). If you use only Ninja indicators then I would think their support department would be keen to know whether it is running properly or whether there are more optimum ways to use it.

Cheers

Travel Well
Reply With Quote
     
The following user says Thank You to ratfink for this post:
     

Old November 10th, 2016, 04:19 PM   #12 (permalink)
Elite Member
Cologne/Germany
 
Futures Experience: Advanced
Platform: NinjaTrader
Favorite Futures: FDAX
 
Posts: 38 since Oct 2011
Thanks: 15 given, 9 received


ratfink View Post
I would not expect to see 100% CPU usage regardless of increased multiple-threading. Moving data between threads is expensive, regardless of the mechanisms used, so that there is often way less benefit than advertised. With much object-oriented software the hardware cores will frequently be stalled in the MMUs or even worse at the page pool if you have excessive data usage (worth checking, but less likely unless you have leak conditions).

Regardless of machine and software, it will always come back to asking whether the right type of charts are being employed for the job - e.g. do you need tick level data for something that could just as easily be seen with a time based series? e.g. do you need to load 100 days when 4 would do? and so, on. Maybe you already did that.

[As a comparison I run multiple workspaces on several machines of varying ages with truckloads of charts and symbols and drawing from custom code under NT7 and average 1.5% cpu pretty much all the time - I simply choose the level of analysis that is optimum and reasonable for each visualisation I want.]

It might be useful if you gave more idea of the charts you use, the memory usage (e.g. working set size, etc). If you use only Ninja indicators then I would think their support department would be keen to know whether it is running properly or whether there are more optimum ways to use it.

Cheers

Thank you!

If I start the program NT8 all charts are opened using 100% CPU. So why not during heavy volume time?

I have not much charts/indicators. If I get the problems I reduce the number of charts and days. It helps a bit.
As far as I understand the problem happens on every CPU: One has just to increase the number of charts and indicators.

If data are moved between threads, should then a 100% usage not even more be demanded?
I don't understand much of this multiple-threading topic.

What do you mean with "working set size, etc"?

Reply With Quote
     

Old November 10th, 2016, 04:39 PM   #13 (permalink)
Market Wizard
Birmingham UK
 
Futures Experience: Intermediate
Platform: NinjaTrader
Broker/Data: IG/eSignal
Favorite Futures: Dax
 
ratfink's Avatar
 
Posts: 2,910 since Dec 2012
Thanks: 9,245 given, 5,659 received
Forum Reputation: Legendary



andorre View Post
Thank you!

If I start the program NT8 all charts are opened using 100% CPU. So why not during heavy volume time?

I have not much charts/indicators. If I get the problems I reduce the number of charts and days. It helps a bit.
As far as I understand the problem happens on every CPU: One has just to increase the number of charts and indicators.

If data are moved between threads, should then a 100% usage not even more be demanded?
I don't understand much of this multiple-threading topic.

What do you mean with "working set size, etc"?

Computing work done is not just cpu cycles. Much of the work in the memory units outside of the cpu takes vastly more cycles to accomplish than a simple instruction, in these cases a core with nothing to do because it is waiting for data is just idle. Having extra threads will make no difference if the memory units are already at capacity, at several levels.

Startup conditions may be different for many reasons - initial library building/optimising, mostly loading of historical data instead of live (e.g. ratio of drawn to off-chart), just depends again what type of charts you are using and days/bars loaded - you haven't said.

I can write you code in NT7 that will use 100% of an 8 core machine, so long as the allocation of work and data to threads makes sense. Even so I can also show that offloading OMD data for example into another thread will achieve almost no benefit because of the memory transfer rate versus cpu cycles gained. In any case the market tick rate is still puny compared to wasted gigahertz cycles, except where grossly inefficient code has been employed.

System architecture is a complex issue, usually overlooked by proponents of OO software and parallel programming because they are usually focused on feature richness far above efficiency, as well as using managed memory languages like C# (which I favour for ease of deployment) but which also comes at a cost.

Working set size/soft faults/hard faults/etc are tools you can begin to look at in the Task Manager/Resource Monitor to see how your system is running under various chart/load conditions.

Cheers

Travel Well
Reply With Quote
     
The following user says Thank You to ratfink for this post:
     

Old November 10th, 2016, 04:59 PM   #14 (permalink)
Elite Member
Ljubljana, Slovenia
 
Futures Experience: Advanced
Platform: NinjaTrader, cTrader, MT4
Broker/Data: CQG, NinjaTrader Continuum, FxPro
Favorite Futures: CL, GC
 
Posts: 23 since Dec 2011
Thanks: 141 given, 19 received

Would be interesting if you could confirm that there is also a maximum of 30% CPU working during heavy volume.

Even less than 30% CPU.
BTW, I'm still on NT7, as I see the same problems in both versions.

Reply With Quote
     

Old November 10th, 2016, 07:58 PM   #15 (permalink)
Market Wizard
Birmingham UK
 
Futures Experience: Intermediate
Platform: NinjaTrader
Broker/Data: IG/eSignal
Favorite Futures: Dax
 
ratfink's Avatar
 
Posts: 2,910 since Dec 2012
Thanks: 9,245 given, 5,659 received
Forum Reputation: Legendary

Futures Edge on FIO

janfilimon View Post
Would be interesting if you could confirm that there is also a maximum of 30% CPU working during heavy volume.

Even less than 30% CPU.
BTW, I'm still on NT7, as I see the same problems in both versions.

In a single (main) thread product like NT7 you would not expect to see more than 12.5% max cpu usage on an 8 core machine, except where other processes are contributing significantly or custom threads have been added.

I do not yet have much NT8 experience (due to the early Air/Alpha nature of the software I have avoided it) but 40 yrs of OS and embedded systems architecture experience tells me exactly what reasonable assumptions I can make.

30% sounds typical to me, assuming the extra threads are sensibly restricted in function, bounded by Windows WPF restrictions and developer choices, modulated by data shifting at sensible levels, especially given that large-scale feature-rich OO/C# is naturally a sparse-access cache-busting architecture.

Would be good to see measured comparisons from others.

Cheers

Travel Well
Reply With Quote
     
The following user says Thank You to ratfink for this post:
     

Old November 10th, 2016, 09:17 PM   #16 (permalink)
Elite Member
Los Angeles, CA
 
Futures Experience: Intermediate
Platform: NinjaTrader
Broker/Data: NinjaTrader Brokerage
Favorite Futures: YM
 
Posts: 83 since Dec 2011
Thanks: 192 given, 124 received

Do you use any custom made indicators?
I had a custom indicator that was very compute intensive and i would see the same behavior. But it was due to indicator.
Do you have the same problem if you only have charts open without any indicators?


Sent from my iPhone using futures.io

Reply With Quote
     

Old November 11th, 2016, 01:58 PM   #17 (permalink)
Elite Member
Cologne/Germany
 
Futures Experience: Advanced
Platform: NinjaTrader
Favorite Futures: FDAX
 
Posts: 38 since Oct 2011
Thanks: 15 given, 9 received


janfilimon View Post
Would be interesting if you could confirm that there is also a maximum of 30% CPU working during heavy volume.

Even less than 30% CPU.
BTW, I'm still on NT7, as I see the same problems in both versions.

I see about 30% for my CPU. I have no experience with producing videos and it doesn't make much sense to produce one. Even if NT8 could get 100% on some other CPU for heavy volume time it doesn't solve the general problem because if I increase the number of indicators even more a time delay would be inevitable.

One simply needs very fast CPUs and not too much indicators in not too many charts.
That's what is becoming clear from this discussion.

Reply With Quote
     

Old November 11th, 2016, 02:07 PM   #18 (permalink)
Elite Member
Cologne/Germany
 
Futures Experience: Advanced
Platform: NinjaTrader
Favorite Futures: FDAX
 
Posts: 38 since Oct 2011
Thanks: 15 given, 9 received


sagor View Post
Do you use any custom made indicators?
I had a custom indicator that was very compute intensive and i would see the same behavior. But it was due to indicator.
Do you have the same problem if you only have charts open without any indicators?


Sent from my iPhone using futures.io

No, I use only NT8 indicators.

I guess if I open enough charts without indicators then the problem has to appear as well.
There is a limit performance of any CPU.

But nevertheless NT should try to code so optimal as possible.

I have other software (not for trading) which can use up to all 8 cores of my CPU (100%!).

Reply With Quote
     

Old November 11th, 2016, 02:13 PM   #19 (permalink)
Elite Member
Denver, CO
 
Futures Experience: Advanced
Platform: NinjaTrader
Broker/Data: NinjaTrader Brokerage
Favorite Futures: ES
 
NinjaTrader's Avatar
 
Posts: 1,182 since May 2010
Thanks: 138 given, 1,755 received


andorre View Post
One simply needs very fast CPUs and not too much indicators in not too many charts.
That's what is becoming clear from this discussion.

That's not clear to me at all. I think your original post stated you had a 17 minute delay? A delay of that length is not due to software not being able to keep up. I offered to help understand your issue and asked you to send us an email. We have not received one as of yet and still wanting to help.

Reply With Quote
     

Old November 11th, 2016, 02:24 PM   #20 (permalink)
Elite Member
Cologne/Germany
 
Futures Experience: Advanced
Platform: NinjaTrader
Favorite Futures: FDAX
 
Posts: 38 since Oct 2011
Thanks: 15 given, 9 received



NinjaTrader View Post
That's not clear to me at all. I think your original post stated you had a 17 minute delay? A delay of that length is not due to software not being able to keep up. I offered to help understand your issue and asked you to send us an email. We have not received one as of yet and still wanting to help.

Yes, I had a 17 minutes delay on my first time Wednesday and on my second try a 20 minutes delay.

In my understanding with a CPU having say 56 cores and every core at least 2 times faster than in my 7 years old CPU I expect that more volume could be processed and so either I have no delay at all or a much smaller one, right??

I had a discussion already last year with NT as I reported this problem. Then, I was disappointed but hoped that NT would solve the problem. But in RC1 and RC2 there is still the same problem. And still I am disappointed.
So, I wanted to hear whether buying a new PC could help to solve the problem. And I think now that there is a general limit for NT8 depending on the particular CPU.

Reply With Quote
     

Reply



futures.io > Futures Trading, News, Charts and Platforms > Platforms and Indicators > NinjaTrader > NinjaTrader 8 chart delays if volume increases

Thread Tools Search this Thread
Search this Thread:

Advanced Search



Upcoming Webinars and Events (4:30PM ET unless noted)
 

Trading Technologies: ADL hands-on

Dec 13

Normal webinar schedule resumes after the holidays

January

Ernie Chan: Risk Management

Elite only

Dedicated Trading Servers: Advantages/Disadvantages w/sam028

Elite only

An Afternoon with FIO member Massive I

Elite only

Leo Murphy: TBA

Elite only
     

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sierra Chart TPO chart + composite volume profile Big Mike Sierra Chart 10 August 2nd, 2016 09:15 AM
TOS Convert to TS - Chart Labels - Daily Volume/Period Volume and Bid/Ask trendfriendpa The Elite Circle 1 November 1st, 2015 04:30 PM
Point and Figure Chart Types in NinjaTrader: Tick vs Volume iwcjimbo NinjaTrader 6 April 5th, 2015 05:40 PM
Ninjatrader indicator that displays the current bar's volume delta on the chart? Zigrivers The Elite Circle 5 November 17th, 2013 01:27 AM
What to Do If You Got Hit by New Tax Increases Quick Summary News and Current Events 0 January 12th, 2013 06:30 PM


All times are GMT -4. The time now is 06:44 AM.

Copyright © 2016 by futures.io. All information is for educational use only and is not investment advice.
There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
 
no new posts
Page generated 2016-12-10 in 0.15 seconds with 19 queries on phoenix via your IP 54.166.37.177