Hello Johnny,
'Yes'. or I should say I eventually managed to reach a Workspace setup that meets my trading needs with which I do not experience charts lagging - and in doing so reached some conclusions about what, IMHO, were significant contributors to the problems I experienced, and happy to share what led me to those conclusions & approach.
So, happy to share insights, give some pointers based on my experience FWIW. However given that everyone's setup is different & I don't know yours, I can probably only give you the 'gist' of how I got to an acceptable result.
In terms of what constitutes success for me - the Workspace I use daily - I trade ES/NQ/RTY/YM. I have 1 workspace open with 3 charts & 1 DOM each instrument. I use ChartLag indicator on one each and almost never see lag through the last 2 years' periods of extreme volatility. When I say almost never, I'll rarely see ChartLag blink orange or red for less than a second under extreme conditions. I never see 'cumulative lag' where charts grind to a slow almost halt for minutes until the platform catches up with processing & making platform inoperable.
There's reference in this thread to internet connection speed/latency & no doubt this, if poor, can and does cause platform lag symptoms but it is not a 'core' issue. I'm sure it was as identified in this thread but it was an anomaly on that occasion, not a core problem so unless you have known issues in this regard, I suggest you dismiss it.
I made two 'fundamental' changes to my setup - number of data series & indicators employed, and chart rendering method used in the indicators.
My Setup is very simple in terms of what I need to achieve from the Platform - basic range High & Low Levels for the Overnight, London and NY Sessions, current & Previous Day i.e. ETH & RTH & London. The only and recommended way to achieve this simple & common day trading requirement is to add a separate data series for each chart for each trading session for each instrument, along with current & previous day OHL indicators for each. This requires rather a lot of data series, indicators etc. 3 Session Data Series per chart x3 charts (fast tick, 10s & 15m), 3 Current & 3 Previous Day indicators, x 4 instruments.
Do the maths & you can see that's a lot. Add a simple VOL and on it goes. Support's response to my lag was to tell me it was because of the number of Data Series, indicators etc. and although subsequently asked me to ignore the reply, had no suggestions as to how to achieve my simple needs more performance-efficiently.
What I did....
I scrapped the above and eliminated Data Series. Rather than one per Session, I use two 3rd party Opening Range indicators with Pre-market Hours. So 'pre-market' gives the Overnight Session, and RTH, and then a duplicate indicator for London hours only. All off one Data Series instead of 3. As I understand it, the 3rd party indicator accesses a Data Series programmatically, as opposed to the Ninja method of adding it to the chart and then making it transparent. I *believe* 3rd party method is more performance-efficient. I use the same 3rd party's Pivot Indicator to get Previous Day HLC values, using a similar approach.
The 'net' result is that I only have one Data Series per Instrument on each chart and 4 indicators instead of the multiple of each using the Ninja core platform solution (plus a couple - VOL, PriceLine, ADR, Tick Refresh etc). A far more elegant solution.
Another difference I believe contributes re: chart lag/rendering is method. The 3rd party indicators use SharpDX which I believe to be more efficient. My knowledge is limited, but from what I've read including Ninja's own Support/Development SharpDX is more efficient & recommended for fast-rendering e.g. their own PriceLine Indicator uses this method for this reason. The core platform OHL etc do not.
I mention in case relevant to your setup - if the charts' indicators use SharpDX method & if not, if alternatives are available which may be worth considering.
Finally, I've seen 3rd party Developers/Coders question the Version age of the core development platform (C#, .net, whatever) being several versions old and contributing to slow speed of code execution of the platform overall, but nothing can be done about that other than by Ninja next major release.
I hope this may be of help to you, and provide food for thought - suggest you strip your setup to the absolute minimum you can live with & get that lag free and only then move forward. And if unable, you may have to take a different route altogether
Kind regards,
'Yes'. or I should say I eventually managed to reach a Workspace setup that meets my trading needs with which I do not experience charts lagging - and in doing so reached some conclusions about what, IMHO, were significant contributors to the problems I experienced, and happy to share what led me to those conclusions & approach.
So, happy to share insights, give some pointers based on my experience FWIW. However given that everyone's setup is different & I don't know yours, I can probably only give you the 'gist' of how I got to an acceptable result.
In terms of what constitutes success for me - the Workspace I use daily - I trade ES/NQ/RTY/YM. I have 1 workspace open with 3 charts & 1 DOM each instrument. I use ChartLag indicator on one each and almost never see lag through the last 2 years' periods of extreme volatility. When I say almost never, I'll rarely see ChartLag blink orange or red for less than a second under extreme conditions. I never see 'cumulative lag' where charts grind to a slow almost halt for minutes until the platform catches up with processing & making platform inoperable.
There's reference in this thread to internet connection speed/latency & no doubt this, if poor, can and does cause platform lag symptoms but it is not a 'core' issue. I'm sure it was as identified in this thread but it was an anomaly on that occasion, not a core problem so unless you have known issues in this regard, I suggest you dismiss it.
I made two 'fundamental' changes to my setup - number of data series & indicators employed, and chart rendering method used in the indicators.
My Setup is very simple in terms of what I need to achieve from the Platform - basic range High & Low Levels for the Overnight, London and NY Sessions, current & Previous Day i.e. ETH & RTH & London. The only and recommended way to achieve this simple & common day trading requirement is to add a separate data series for each chart for each trading session for each instrument, along with current & previous day OHL indicators for each. This requires rather a lot of data series, indicators etc. 3 Session Data Series per chart x3 charts (fast tick, 10s & 15m), 3 Current & 3 Previous Day indicators, x 4 instruments.
Do the maths & you can see that's a lot. Add a simple VOL and on it goes. Support's response to my lag was to tell me it was because of the number of Data Series, indicators etc. and although subsequently asked me to ignore the reply, had no suggestions as to how to achieve my simple needs more performance-efficiently.
What I did....
I scrapped the above and eliminated Data Series. Rather than one per Session, I use two 3rd party Opening Range indicators with Pre-market Hours. So 'pre-market' gives the Overnight Session, and RTH, and then a duplicate indicator for London hours only. All off one Data Series instead of 3. As I understand it, the 3rd party indicator accesses a Data Series programmatically, as opposed to the Ninja method of adding it to the chart and then making it transparent. I *believe* 3rd party method is more performance-efficient. I use the same 3rd party's Pivot Indicator to get Previous Day HLC values, using a similar approach.
The 'net' result is that I only have one Data Series per Instrument on each chart and 4 indicators instead of the multiple of each using the Ninja core platform solution (plus a couple - VOL, PriceLine, ADR, Tick Refresh etc). A far more elegant solution.
Another difference I believe contributes re: chart lag/rendering is method. The 3rd party indicators use SharpDX which I believe to be more efficient. My knowledge is limited, but from what I've read including Ninja's own Support/Development SharpDX is more efficient & recommended for fast-rendering e.g. their own PriceLine Indicator uses this method for this reason. The core platform OHL etc do not.
I mention in case relevant to your setup - if the charts' indicators use SharpDX method & if not, if alternatives are available which may be worth considering.
Finally, I've seen 3rd party Developers/Coders question the Version age of the core development platform (C#, .net, whatever) being several versions old and contributing to slow speed of code execution of the platform overall, but nothing can be done about that other than by Ninja next major release.
I hope this may be of help to you, and provide food for thought - suggest you strip your setup to the absolute minimum you can live with & get that lag free and only then move forward. And if unable, you may have to take a different route altogether
Kind regards,
Comment