Announcement
Collapse
No announcement yet.
Partner 728x90
Collapse
NinjaTrader
Make chart refresh rate faster than 250ms possible
Collapse
X
-
-
Have not yet installed it, but already a very big "THANK YOU VERY MUCH!!" to you from my side!
Great you are sharing your indicator with us!
- Likes 1
Comment
-
I have been using since my last post, set to 100ms/on price change, on my main entry chart only. Difference, especially with my price line on is stunning. Much, Much better for my purposes. Ninjatrader staff should be ashamed! Seriously. Once they try this (if any of them trade), they might realise what we've all been harping on about for the last few years...
- Likes 1
Comment
-
thanks for sharing this simple trick - was using in other parts of code for some other aspects - but this is a simple all in one short indicator workaround which affects the whole chart i presume
Will test it out ; these instances really show the contribution and collaboration of ideas when ninja falls short and its like crickets in here with zero ninjatrader input.
So a question even though posts below state that the InvalidateVisual() is queued and another onrender even setting this to 100ms is an improvement on the current 250ms?
Any confirmation appreciated
thanks
- Likes 1
Comment
-
explorer101. I would say it makes a visual difference. See this video 100ms vs default https://youtu.be/0sb8OANbcyo
- Likes 1
Comment
-
Hurleydood (& anyone else ....)
Some clarifications please ahead of trying this, if you would be so kind....
If I understand correctly from your posts and others, TickRefresh works per chart so I can apply it as and only where desired to have a chart refresh faster than 250ms.
The common use case I imagine (at least in the context of this thread and per PJSmith's post) - I can put it on my fast/order entry charts only, set to (say) 100ms to get 0.1sec refresh on those charts only? (hence no unnecessary hit to PC performance by increasing refresh on slower charts where doing so adds nothing)
As an approach to deploying this across my trading setup, I might, for example, use it on an NQ or FDAX 15 tick or 5s chart set to 100 or even 50ms to assist during times of high market activity & volatility, but not use it at all on Bonds, or even ES where 250ms is adequate (in my experience and for my trading).
Depending upon what I find as a consequence of using it (any significant hit to performance as I increase the number of charts I use it on), I *might* use it to slow refresh in order to save resources e.g. slow the refresh to 1000ms on Minute charts?
Simply put, it seems to give me back what we had in NT7 - the ability to custom set chart refresh speed per chart, rather than the one-size-fits-most blunt instrument 250ms solution imposed on us in NT8. However we should use this cautiously and intelligently to avoid the problems the blunt instrument approach sought to protect users from.
Does anyone have any comment on the health-warnings NT give in Help on using this code in this way in the context of the above i.e. regarding potential to hit 'deadlocks'? (I don't speak much conehead, so it would be helpful for me to know what 'hitting a deadlock' will look like in practice). My setup is very stable now, with some occasional hiccups outstanding/being investigated but not with much progress. Hence I am reluctant to introduce anything new that might deflect from finally putting those to bed. I'm hoping that a 'common sense' approach of adding one instance of the indicator set to 100ms to a 'mid level' example (say YM 25tick chart) and watching CPU and GPU load at market open/news is the way to go, then if all well NQ, FDAX, RTY etc can follow, incrementally. And keeping an un-adulterated back-up of my setup such that I can simply revert.
What I am asking is what to look out for if problems occur, to as far as possible identify that it is this that has caused them, not something else - chart freeze, sluggishness until processing 'catches up' I guess? Anything else to confirm or eliminate, e.g. from Log and Trace file, or Log tab in Control Center
Many thanks for contributing and sharing. If it works well, two years to re-instate NT7 functionality in order for chart traders to properly benefit from NT8 CPU multi-threading/offloading to GPU, rather than go backwards
Kind regards,
- Likes 2
Comment
-
brucerobinson Yes, you understand correctly. The change only applies to the specific chart you applied the indicator to. If NT were to re-introduce the feature that was in NT7, we could of course set our long term charts to a much longer interval than 250ms, and save resources there, too.
As you say, I think it needs to be applied with some restraint to prevent issues. I applied it to my entry charts only and as it is primarily price action I wanted it for (not volume indicators, etc.), I set it to on-price change. I think, using on-price change is the perfect efficiency option, because, unlike NT7 where it will blindly invalidate per the interval, we only update here, if price has actually moved.So, I'm getting an update every 100ms, but only if price has changed. I changed it to 50ms now, just to see, but I noticed no difference in performance of my platform at all.
The difference in chart behaviour is stunning though and this single change has prompted me to reconsider migrating to something else.
In terms of if it will make your platform unstable. I've been running the same method used in this indicator for a couple years in my own order entry logic, without realising! I never put 2+2 together, else I would have coded this long ago! I have never had issue with this call. Obviously, it's being used far more frequently here, but I was running it and trading live since my post, all day the remaining days of the week for the full eu and us sessions, and I had no issues at all, just lovely printing bars, one at a time in fast moves, rather than a 'where did those 5 bars come from' type update.
I would guess the only issue is going to come with the number of visible drawing objects on the chart at the time the chart is refreshed. My charts have a lot of algo type marks on them, so maybe worse than some, but still, I noticed no issues. Entry charts are likely going to be covering small time frames, lessening this issue anyway.
I note the author has already removed some of the redundant code and made it more efficient. I'd already done some tinkering in that respect too. In it's latest form, it looks good to me. If I notice any issues, I will post them here.
Last edited by pjsmith; 03-30-2019, 07:30 AM.
- Likes 2
Comment
-
Thanks pjsmith for comprehensive reply.
"If NT were to re-introduce the feature that was in NT7, we could of course set our long term charts to a much longer interval than 250ms, and save resources there, too."
To be clear - if we found the need, to offset/free up resources consumed by usińg 100ms, we could use this indicator also for the purpose you describe (no need to answer if this is so - basically the availability of this allows us to tinker any and all charts faster and slower as NT7 before to optimise to individual requirements).
"On price change" - yes indeed, me too, a no-brainer in resource efficiency terms
Platform stability experience with it, drawing objects etc - thanks for the feedback, it is re-assuring in order to move forward
I'm bordering on being excited to give it a go!
I'll post my progress, warts and all if any.
Best,
- Likes 1
Comment
-
For info, I'm not sure we can use this indicator to save resources on charts that do not need refresh very often. As far as I understand it, it does not overwrite the inbuilt 250ms timer, so that will run regardless, if there are chart updates to be made. I;m not expecting to have to go to these lengths anyway, to be honest.
- Likes 1
Comment
-
Ah, I see what you mean, longer refresh in the indicator won't over-ride the hard-coded 250ms. Good point well made. Thanks for taking the time.
Likewise, I'm hoping & expecting we can simply tinker with this only with the charts that will benefit, without bringing things to a standstill or anything close.
If it did, i'd probably take that as sufficient reason to cease and desist at this point for now.
Thanks
- Likes 1
Comment
-
Originally posted by brucerobinson View PostIf I understand correctly from your posts and others, TickRefresh works per chart so I can apply it as and only where desired to have a chart refresh faster than 250ms.
Originally posted by brucerobinson View PostThe common use case I imagine (at least in the context of this thread and per PJSmith's post) - I can put it on my fast/order entry charts only, set to (say) 100ms to get 0.1sec refresh on those charts only? (hence no unnecessary hit to PC performance by increasing refresh on slower charts where doing so adds nothing)
Originally posted by brucerobinson View PostAs an approach to deploying this across my trading setup, I might, for example, use it on an NQ or FDAX 15 tick or 5s chart set to 100 or even 50ms to assist during times of high market activity & volatility, but not use it at all on Bonds, or even ES where 250ms is adequate (in my experience and for my trading).
Depending upon what I find as a consequence of using it (any significant hit to performance as I increase the number of charts I use it on), I *might* use it to slow refresh in order to save resources e.g. slow the refresh to 1000ms on Minute charts?
Originally posted by brucerobinson View PostSimply put, it seems to give me back what we had in NT7 - the ability to custom set chart refresh speed per chart, rather than the one-size-fits-most blunt instrument 250ms solution imposed on us in NT8. However we should use this cautiously and intelligently to avoid the problems the blunt instrument approach sought to protect users from.
Originally posted by brucerobinson View PostDoes anyone have any comment on the health-warnings NT give in Help on using this code in this way in the context of the above i.e. regarding potential to hit 'deadlocks'? (I don't speak much conehead, so it would be helpful for me to know what 'hitting a deadlock' will look like in practice). My setup is very stable now, with some occasional hiccups outstanding/being investigated but not with much progress. Hence I am reluctant to introduce anything new that might deflect from finally putting those to bed. I'm hoping that a 'common sense' approach of adding one instance of the indicator set to 100ms to a 'mid level' example (say YM 25tick chart) and watching CPU and GPU load at market open/news is the way to go, then if all well NQ, FDAX, RTY etc can follow, incrementally. And keeping an un-adulterated back-up of my setup such that I can simply revert.
What I am asking is what to look out for if problems occur, to as far as possible identify that it is this that has caused them, not something else - chart freeze, sluggishness until processing 'catches up' I guess? Anything else to confirm or eliminate, e.g. from Log and Trace file, or Log tab in Control Center
It also works great in Market Replay mode if you want to test out your set of indicators. Check out this video with Market Replay at maximum speed.
I ran some analytics and a new version will be out next week with improvements.
- Likes 2
Comment
-
I didn't see Hurleydood's reply until now. Despite being Subscribed sometimes I don't seem to get Notifications.
Firstly a big thanks for taking the time to give the comprehensive answers to my wonderings - whilst I don't know much about what goes on under the hood, it is comprehensible and all makes sense, seems very well thought through/out and hence re-assuring.
By way of my contribution - to report back, I've been using the indicator on all my 'fast' (typically 15-50 tick) charts on faster instruments (usual suspects, FDAX, US Indices, CL etc) running 13hrs most days, for a week. So circa 600 'instrument hours', news events, Closes etc)
No discernible performance hit, at any time (I have a CPU LCD permanent read-out).
No discernable deadlocks in the manner you helpfully expanded upon for me, e.g. slowdown/catchup behaviour.
I have noticed a few 'Error in realtime market data handling....' type errors in the log. I mention this in no way 'casting aspersions' that the indicator is responsible - I don't usually look for log errors unless I am experiencing a problem or trying something new.. It is not to say that similar aren't there otherwise, nor that it is a problem, as such. It may be 'normal behaviour'/to be expected with or without this indicator applied. I only mention because you/others may, or may not, find it useful to know and/or know with certainty such errors are nothing to do with 'what this does and how it does it', (so don't be offended! it's simply above my pay-grade to know).
I'll keep a watching brief and report again with more ticks under the belt
Current status/impressions - bloody marvellous, not from a geeky perspective that it can be done, but from a trading perspective seeing price on a chart next to the DOM moving in glorious synchronised harmony. Heavenly.
Kind regards,
- Likes 3
Comment
-
Thanks for your input Bruce. I released a new version last week, please give it a test. I haven't seen the error you mentioned myself but I'll keep a look out. Can you check your NT8 Log directory to see if the error has been seen prior to the indicator been used?
Yes it's great to see the DOM synchronized in harmony with the chart. I trade primarily from the DOM but I can easily trade from the chart as well now. You can actually see realtime price action on the chart now.
- Likes 1
Comment
Latest Posts
Collapse
Topics | Statistics | Last Post | ||
---|---|---|---|---|
Started by nicthe, 08-23-2023, 07:53 AM
|
7 responses
196 views
0 likes
|
Last Post
by nicthe
Today, 09:26 AM
|
||
Started by nicthe, Today, 09:24 AM
|
0 responses
5 views
0 likes
|
Last Post
by nicthe
Today, 09:24 AM
|
||
Started by stalt, 12-28-2015, 01:36 PM
|
6 responses
1,536 views
0 likes
|
Last Post
by giulyko00
Today, 09:16 AM
|
||
Started by Tburg1073, Today, 08:36 AM
|
0 responses
7 views
0 likes
|
Last Post
by Tburg1073
Today, 08:36 AM
|
||
Started by alexstox, 10-16-2018, 03:29 PM
|
10 responses
334 views
0 likes
|
Last Post
by Tburg1073
Today, 08:32 AM
|
Comment