After updating to NT 8.1.7.0, I’m seeing the default PriceLine indicator lag slightly behind the right side price marker.
This is using NT’s default PriceLine indicator with the Last line option. The right-side marker is the Data Series price marker from: Chart Properties > Data Series > Price marker visible
Before the update, the PriceLine and price marker rendered in sync. It seems like NT’s stock PriceLine is now slightly delayed while plotting the Last price from OnMarketData through OnRender.
Could it be that the Price Marker is now updating 50ms, whereas the Price Line remains @ 250ms, so it is ‘slightly delayed’ for up to 200ms until the fifth Price Marker refresh/Price Line refresh coincide?
This is a new feature where marker is updated 5x faster (every 50ms) than the chart (250ms). After a while you get used to it - if you do not use the price line. IMO, NT should add price line to the price marker so it moves with it.
I tested 8.1.7.0 for a week and it’s beta quality at best. I love the new features (color picker!) but unfortunately, aside from small bugs, it has a major issue with sluggishness that others have reported as well.
Bruce and Bill are spot on. It is a thread priority desync inside the 8.1.7.0 update
The stock PriceLine indicator runs inside the standard OnBarUpdate pipeline and handles its drawing vectors inside OnRender, which is bound to the main 250ms UI chart canvas refresh loop, the Data Series price marker on the right axis bypasses the chart canvas entirely. It is hooked directly to the raw market data interface wrapper updating every 50ms
Recompiling a custom script won’t fix it because any code executing inside the native NinjaTrader.Gui.Chart namespace will still get throttled by the core canvas limitations, if you want the horizontal line to stick to the price marker without that 200ms visual drift during fast fast liquidity sweeps, you have to bypass OnRender completely and use SharpDX/Direct2D device contexts to force immediate drawing updates straight into the window handle. Ninja basically tried to make the platform look fast by overclocking the axis while leaving the actual rendering engine lagging behind.
I, a long time ago, tried to refresh not at the default 250ms speed, but at 50ms. Even with just 1 workspace open, there was a huge lag. In very volatile markets, the charts where several points behind on the market. My CPU was a Ryzen 9 AMD, but he could not catch up. With 50 ms refresh rate my charts were still busy trying to show the quotes from many seconds ago. When the market calmed down, my charts still continue to change as fast as possible for at least 10-20 seconds.
#marcus I believe your point that one should ask one’s self do I/why do I need refresh faster than 250ms is well made and a good question anyone considering this issue should ask, and particularly if thinking about using TickRefresh.
If I may, & to reflect on why we’re talking about this…
This thread was started because of an unintended consequence of the 50ms Price Marker update out of sync with the chart 250ms Price Line ‘causing confusion’/prompting comment.
This is a result of Ninja’s action to do this to address the fact that some users find their 250ms chart refresh restriction inadequate. I.e. the 50ms Price Marker/250ms chart refresh anomaly is a consequence of the retrograde 250m chart throttling introduced in 8 and the 50/250 ‘lag’ anomaly a consequence ‘own goal’ of a poor man’s workaround to address the 250ms chart restriction (clearly doing this is acknowledgement that some Users find it a problem and competitors’ products better. Marketing weasel-words ‘it makes your charts look faster’ )
Looking back to why TickRefresh was developed in the first place, it was because a User noticed NT8 charts were visibly slower refreshing c/w NT7 and found it problematic in use (Like watching a 1920’s movie. It was a retrograde step with practical consequences for some Users)
So where are we 8 years or so since NT8 250ms (NT8 being an architectural update to take advantage of multiple cores)? NT has introduced Price Marker update to try to give the appearance of faster chart update/chart platform responsiveness rather than doing so, in and of itself an acknowledgement that chart refresh at 250ms isn’t fast enough for some users and inferior compared with competing products
And to your point, Price Marker 50ms update per se is pointless because it’s too fast to see - so at best its only benefit is if it gives the impression the platform/charts are faster
To your point does one really need TickRefresh? I use it only on one fast chart per instrument, along with a DOM, where like it’s developer I find 250ms insufficient in fast markets.
I can’t help but re-iterate - NT7 did this without all this nonsense, and 8 was supposed to be a drum-roll multi-threading performance upgrade
You really couldn’t make this stuff up. Own goal after own goal after own goal hence the well-earned & deserved roastings
I think that each trader has its own vision based on what he trades, how he trades, his trading plan, etc…
But I am always interested in what other people are doing, as you never know what you can still learn.
My vision is:
As I daytrade several times a day, good entries are the most important thing, so I focused hugely on that.
What is also hugely important is reduce risk of having big open p&l while being in a trade. So I don’t need the best price, but the best price with the smallest moves in the wrong direction while in a trade.
Trend is important too.
What is the result:
I have on average 300ms fills.
I have very small open p&l losses which are mostly 4-8 ticks ES.
My average stay in position can go from 15 minutes to several hours, depending on the trend.
So do I need 50ms refresh?
No, I did tests with real trades in which I changed the real profit by using worse entries and exits.
If I add 4 ticks, 8 ticks, or 16 ticks lag for execution my profit is still close to my actual profit.
On the other hand, if I get a 300ms fill, my price (always market orders) can even be better than expected. Prices don’t always go in the same direction. They can also go fast up and down, resulting in better fills.
So, trying to improve this 250ms refresh rate would have no noticeable impact on my results. Always using market orders make it also impossible to go faster as I have to place the order at the moment when I get a signal. That order goes from my PC to themarket and back. So very fast executions are impossible. I should need a server close the the CME and orders should already be on the server for execution, not on my PC.
You are trading ES that moves like molasses compared to NQ. Higher refresh allows to see things on the chart that you can spot on the DOM. Other platforms update even faster than 50ms so that’s what NT has to compete with.
I do trade the NQ too. With the same PC and the same charts. Only the stops are a bit further away as NQ is “wilder”. Leverage in NQ is also lower because of that.
Results are more or less the same (profit per trade, number of winning trades, avg loss, avg profit).
I even use it for Forex, and a slower version for trading stocks.
But as I never trade “buy the bottom and sell the top” my entries are much more balanced and have a much better reward to risk ratio.
Always interesting to hear of other Users’ use cases, whether for chart or price marker refresh.
This thread was initiated due to PriceLine/PriceMarker mismatch, to which I contributed I thought may be something I’d already commented on - being the to my mind incredulous claim that speeding up price marker would make charts seem faster!
The rest, as they say, is history - NT8 restricted chart refresh which some Users noticed and found unsatisfactory to the extent an app was built. Meantime, competitors have seen advantage in making refresh even faster.
'Nuff said
FWIW I run TickRefresh @ 17ms (same as 60Hz monitor refresh) on NQ and it suits me
One of the reasons I comment on ‘related matters’ is to keep abreast. Someone mentioned they thought a ‘hidden panel’ is in preparation for release which may allow user control of chart refresh, & which may be ‘responsible’ for the usual new release slow load, lag etc
)
