Important Poll: Everyone Please Respond

[JS999]

I must say that this is very important for me as I have more then 23 charts on 5 monitors plus about 15 more that are minimized and only a few are set at 0.5 all the others are set at way higher time frame I have some that are set at 360 sec as they are bigger time frame like weekly monthly, so no need to have them refreshed every half second I must say that I use 6.5 and that my PC rarely freezes with these settings, so I would be afraid of having issues if I have not the possibility to put bigger refresh settings on all my charts.

P.S I know this is weird but I want the refresh not for same reasons as others.

Thanks

Larry, your post illustrates exactly why their refresh rate change is such a bad idea, and why configurable settings like 6.5 are so important. Some people like me want a 20 second chart to update at least 10 times a second, and some people like you want a monthly chart to update every 5 minutes. They really should have known about this type of problem and left things as they were, possibly eliminating the option to update the display with each incoming tick if they were really concerned about performance. I can't believe that this global .5 second refresh idea actually made it out of the first design meeting. In any case, I'm not too worried about this right now... given the way that the community is responding, I can't see how they're going to be able to leave it as is. If they want to wait a bit longer, fine... but I think that this change will end up in the software.

[mjc4118]

Ok ... I am sticking my head in here and it will probably be chopped off ...but... Having been in software development for over 15 years and understanding the nature of the windows operating system and system development in general... give the boys at ninja a break. As users we ask for everything and expect it. As developers they simply can't provide EVERYTHING. Developing systems as complex as NT7 is, are a development nightmare. Additionally the platform application/implementation methodology and users expectations are all over the map.

An IP packet takes 50 or more ms (probably more like 70 to 120 ms) to reach your computer from your data provider. The data you are receiving is already out of date. It took at least 60 ~ 120 ms to make it into your data providers systems and be relayed to you. So no matter how fast your charts refresh your problem of having your data delayed will never be solved by Ninja alone.

Just like there is a solid right edge to your charts there is a solid right edge to the ability to create the magic called software. If they do not take into consideration the hardware and software limitations of users machine (the average user... not EVERY user) The user limitations and ignorance level that will more often than not cause perfectly good software systems to implode then they would be engineering for disaster not a successful application. There is no "USER" UPGRADE!

That being said ...Personally, I believe that "candle close" should be the predomanant factor in determining when a paint instruction is given... Any updates that occur to the canvas before then can be updated every 500 ms or whenever the application so desires...As long as when my candle closes I get fast paint and results on my screen. I work on 89 and 144 tick charts ...so I use fast charts. If you are scalping for 1 tick and cannot seem to get data fast enough you can pony up 2 or 3 million to write your own application. Just simply beating the heck out of the developers for the sake of beating the hell out of them seems redundant. There are features I want that I KNOW they will not provide. I also paid for a full license. Such is life.

[eDanny]

... Having been in software development for over 15 years and understanding the nature of the windows operating system and system development in general... give the boys at ninja a break. As users we ask for everything and expect it. As developers they simply can't provide EVERYTHING.

This does not even make sense since the setting was available in 6.5

An IP packet takes 50 or more ms (probably more like 70 to 120 ms) to reach your computer from your data provider. The data you are receiving is already out of date. It took at least 60 ~ 120 ms to make it into your data providers systems and be relayed to you.

All the more reason to update charts quickly if the user wants. Lag + lag + lag = bad, lag + lag + less lag = slightly better.

That being said ...Personally, I believe that "candle close" should be the predomanant factor in determining when a paint instruction is given...

Not everyone wants chart updates on candle close, in fact I know of no one.

[cls71]

cls71, it's good to realize that we can actually manually change the refresh rate ourselves through code. I'm assuming that if I just check the current time inside the OnMarketData() event handler and choose to call Refresh() or Invalidate() every 100 ms, that this will work? If I made an indicator that did that, would it automatically refresh the entire chart and all indicators on it at that interval? I also can't find any documentation on Refresh() or Invalidate()... maybe I missed it. Is there a difference between the two?

I hope explain correctly. My English is not very high.

The limit of 0.5 seconds only affects the visual appearance. In particular, Plot method execution.

If you run automatic strategies will have no negative effect. None. On the contrary, could be beneficial.

Really only affect a discretionary trader able to make decisions in less than 0.5 seconds based on the reading of a chart.


Overwriting OnMarketData method can force the Plot method is executed with every incoming tick.
With efficient planning calls ChartControl.Refresh () will not adversely affect your performance.
This is a simple example where the chart is refreshed with each incoming tick. If you run this code, the entire chart will redraw with each incoming tick including all indicators that have loaded.

Refresh and Invalidate are members of the Control class. You can find lots and better documentation on MSDN and google.
Refresh() redraws the entire client area (the entire chart) while with Invalidate() can specify the region to be redrawn.

Best Regards

PD:
you can also set a Timer object to redraw a time interval, instead to redraw in each incoming tick.

[mjc4118]

Not everyone wants chart updates on candle close, in fact I know of no one.

See Danny... you have proved the point that everyone wants something different and no one can imagine every different persons requirements. They cannot develop for all possible scenarios. But, I would be curious what eSignal and other charting application providers offer as their solution to this problem.

[NinjaTrader_Ray]

See Danny... you have proved the point that everyone wants something different and no one can imagine every different persons requirements. They cannot develop for all possible scenarios. But, I would be curious what eSignal and other charting application providers offer as their solution to this problem.

TradeStation and eSignal don't provide any option as far as I know and is the case (I could stand corrected) for most other platforms also. You just don't know if they update once per second, 10 x per second etc and my guess is that they will not tell you.

[darthtrader]

Really only affect a discretionary trader able to make decisions in less than 0.5 seconds based on the reading of a chart.

cls71, thanks for that code but there is no reason for snide comments as this is a big deal to some people.
The problem with the code though is this puts anyone interested in using this into unsupported territory. I'm sure everyone interested in this understands lag, its besides the point. The point is this was in 6.5 and now its gone without a hack. There is a large difference between putting everything in anyone can possible want and having the choice of when the chart refreshes.
While JS999 has been quite over the top in this and probly a bit counter productive, he does have a point.
Personally, I could care less if candle sticks were even included in the package for my own trading but I would find it odd if candle sticks were removed just because it creates support issues because some customers are to stupid to figure out how to use the software for their own needs optimally.
Which I assume was the main reason this decision was made in harsher language.

I don't know what else there is to discuss other than the promise of a future update to fix this issue. With the beta rolling out there is obviously more pressing issues with bug fixes.

[JS999]

Ok ... I am sticking my head in here and it will probably be chopped off ...but... Having been in software development for over 15 years and understanding the nature of the windows operating system and system development in general... give the boys at ninja a break. As users we ask for everything and expect it. As developers they simply can't provide EVERYTHING. Developing systems as complex as NT7 is, are a development nightmare. Additionally the platform application/implementation methodology and users expectations are all over the map.

You're right, you are going to get your head chopped off. What the hell are you talking about? Everything you said is complete nonsense, given that they already had this feature in 6.5 and took it out. We aren't talking about some magical special feature that they decided they couldn't implement, we are talking about a basic part of the software that already existed and worked just fine in the previous version of the code.

An IP packet takes 50 or more ms (probably more like 70 to 120 ms) to reach your computer from your data provider. The data you are receiving is already out of date. It took at least 60 ~ 120 ms to make it into your data providers systems and be relayed to you. So no matter how fast your charts refresh your problem of having your data delayed will never be solved by Ninja alone.

So by this logic, why not just add in an extra 2 seconds of delay then? I am not asking Ninja to solve the problem of internet lag, I am asking them to grow a brain and not ADD to it for no reason at all. If I get a tick that comes in at the 100 ms mark, I want it displayed as soon as possible on some of the shorter term charts. I don't want "Big Daddy NinjaTrader" to decide what is good for me and artificially delay me seeing this tick for up to 500 milliseconds. Get it? This is the type of thing that is going to COST ME MONEY on some trades eventually. There are certain features that are optional and "nice to have" on a piece of trading software, but this isn't one of them. This is a critical feature that they absolutely must put back in, or it's sayonara to NinjaTrader not only for me, but for most of the rest of the scalpers out there in the world that trade fast-moving instruments. I can't believe that this is even a discussion... what a friggin' waste of my time. It's like I'm trying to convince an auto manufacturer to make sure that they include a steering wheel in the car they sold me.... and now Ray is taking his sweet time asking for opinions from other traders as to whether they would like a steering wheel or not before deciding what to do. I have no words for how friggin' ridiculous this entire conversation is.

Just like there is a solid right edge to your charts there is a solid right edge to the ability to create the magic called software. If they do not take into consideration the hardware and software limitations of users machine (the average user... not EVERY user) The user limitations and ignorance level that will more often than not cause perfectly good software systems to implode then they would be engineering for disaster not a successful application. There is no "USER" UPGRADE!

AGAIN, this already existed and worked just fine in 6.5. They arbitrarily removed it and crippled our ability to change the refresh rate for no reason at all, other than they felt that they didn't want some stupid people accidentally making the settings too aggressive and causing them PR and customer service headaches. It was a purely 100% selfish move that benefits nobody but them, and doesn't even benefit them that much considering how much some people (like me) are giving them flak about it. If you think what I am saying now is bad, just wait until I get on all the other more public message boards and start telling every scalper in the world to avoid NT 7 because of this issue... that is, if they are stubborn and don't change it.

That being said ...Personally, I believe that "candle close" should be the predomanant factor in determining when a paint instruction is given... Any updates that occur to the canvas before then can be updated every 500 ms or whenever the application so desires...As long as when my candle closes I get fast paint and results on my screen. I work on 89 and 144 tick charts ...so I use fast charts. If you are scalping for 1 tick and cannot seem to get data fast enough you can pony up 2 or 3 million to write your own application. Just simply beating the heck out of the developers for the sake of beating the hell out of them seems redundant. There are features I want that I KNOW they will not provide. I also paid for a full license. Such is life.

So .5 second refresh is fine for you... good for you. That doesn't mean it's fine for everyone. Do you trade crude oil? Because if you are trading something slow moving like bonds or the ES, who cares how fast the chart updates, that stuff hardly moves more than 1 tick at at time. The point is that the software is supposed to be usable for all instruments, and with this setting it's not. Not to mention the other problems mentioned about not being able to set the refresh to a longer time period than .5 seconds, which is necessary for some very long-term charts to make sure that they don't eat up the CPU unnecessarily.

The only reason that Ninja made this change is that they didn't want to deal with people accidentally setting the charts to too short of a refresh period, and complaining about it later... and that is definitely not a valid reason to limit the software for everyone else.

[JS999]

While JS999 has been quite over the top in this and probly a bit counter productive, he does have a point.

I agree that I have been somewhat over the top about this, and that it is probably counter-productive - sorry about that.

But this is not a trivial issue, and I am extremely pissed off right now that they felt that they had the right to arbitrarily change this, and that I had to start a poll and raise a stink to attempt to get it back in. One of the reasons I picked NT in the first place was specifically because it was touted as being able to process and display information as soon as it came in, particularly with Zen-Fire.

The fact that they feel that they can just remove this type of major feature without our consent REALLY, REALLY pisses me off. This is not about some minor chart study that they removed from their list... this is them screwing around with my data and affecting when I see something that has already happened. I never would have picked NT if they had had a .5 second refresh in 6.5, and this feels a heck of a lot like a nasty bait-and-switch.

If there is a hack that I can use with that OnMarketData() function to update my display every 100 ms or so, then I can live with this. Not ideal by any means, but I'm used to hacking things to get around NT's limitations. It won't solve the problem with longer term charts not being able to refresh at periods longer than .5 seconds, though.

I don't know what else there is to discuss other than the promise of a future update to fix this issue. With the beta rolling out there is obviously more pressing issues with bug fixes.

All I want is a guarantee that they are going to fix it. I can live with the delay for a little while, but they should fix this before it goes out on public beta.

[VTtrader]

I posted this over on the Zen-Fire Lag thread but felt it would be fitting here as well since it is about NT7 http://www.ninjatrader-support2.com/...t=20238&page=6

I've added some additional comments at the end.

Great Job on NT7 performance enhancements Ray and all!

Just had my first ES open with NT7 using the TickTimePlot indicator and the improvement is remarkable. In the past it was showing lags up to 16 seconds on the open, see the attached picture for the results with NT7.

Pre-open there is one spike (about 2.5 senonds) when I loaded an indicator in another chart prior to the open. The generally higher values prior to the open are due to the fact that with slower price action, there is no way to tell if the first tick of the second was at +0 ms or +999 ms. Once the market is open and the ticks are coming faster, you're more likely to have the first tick of the second being closer to +0 ms.

Average lag using NT7 when the market is open is averaging around .2 seconds. A major improvement!

Glad to report such good news.

VT

The performance enhancements have been truley amazing in NT7. As you can see in the picture NT7 stayed rock solid during the ES open when multi-second lags (sometimes as long as 16 seconds) have been the norm even with the default .5 second refresh rate in NT6.5.

I scalp most of the time also, and have had my stop/target hit when I didn't even see the price near that level. I used to think that it was the chart refresh frequency, but cutting that down didn't help much if at all. What the problem was, was that the lag that was experienced when a flurry of trading activity came from the exchange. and that activity takes time and CPU cycles to be processed. It didn't matter what the refresh rate as set at, it wouldn't have changed the outcome of the trade. So it comes down to a trade off, do you want that time/CPU cycles to be processing the surge in data or redrawing the chart. IMO it is much better to see current data redrawn every .5 seconds then several second old data redrawn every .1 seconds.

That said, if putting the "option" in for people to decide for themselves, that IN NO WAY would effect the performance gains unless you chose to change it, then why not include it.

As a side note, the DOM might be a better way to go if .5 seconds is to lagged, since the DOM will process it faster than the chart ever will.

Just my opinion.

VT

[JS999]

The performance enhancements have been truley amazing in NT7. As you can see in the picture NT7 stayed rock solid during the ES open when multi-second lags (sometimes as long as 16 seconds) have been the norm even with the default .5 second refresh rate in NT6.5.

I am glad to see that they have made improvements on this front... it makes the .5 second refresh issue even more maddening.

So it comes down to a trade off, do you want that time/CPU cycles to be processing the surge in data or redrawing the chart. IMO it is much better to see current data redrawn every .5 seconds then several second old data redrawn every .1 seconds.

On your PC, on your chart setup, on your trading system, this was the case. I can tell you for a fact that on my super-fast and optimized trading setup, even on NT 6.5, I was not seeing significant lag because I had only a very few short-term charts open without a lot of lookback period. So in my case, having an artificial .5 second delay is ridiculous, because my system can easily handle the data refreshing at 100 ms. The fact that yours can't doesn't mean that other people like me should be limited.

That said, if putting the "option" in for people to decide for themselves, that IN NO WAY would effect the performance gains unless you chose to change it, then why not include it.

Good idea. Hopefully they will listen.

As a side note, the DOM might be a better way to go if .5 seconds is to lagged, since the DOM will process it faster than the chart ever will.

Just my opinion.

VT

You can't scalp something like crude oil off of the DOM. You need a short-term chart to do that, and you need it to be as responsive as possible. (Incidentally, the DOM is not refreshed the same way as far as I understand, but I could be wrong.) By removing this feature they are crippling a very important tool for some people like me.

[eDanny]

Slightly off topic but referring to a couple posts back, I jus ran TickTimePlotV2 on NT7 and I get wicked bad results compared to 6.5. Any Idea why?

[JS999]

I never really got an answer to my question regarding the ChartControl.Refresh() function. If I put a line like this into OnMarketDepth:

if (DateTime.Now > lastRefresh.AddMilliseconds(refreshDelay))
{
ChartControl.Refresh();
lastRefresh = DateTime.Now;
}

Is that going to automatically refresh the entire chart and re-calculate all the indicators every refreshDelay milliseconds? The idea would be to create a "blank" indicator that did nothing but this, and add it to whatever chart I wanted refreshed at a faster rate.

I am thinking of adding it into OnMarketDepth() since that changes very frequently. On the other hand, if I put it into OnMarketData(), and if there is no trade data or Level 1 data change coming in, then it will just refresh at the .5 second mark, correct? I want to make sure that this will work as I think it will, and that there won't be any unexpected consequences or side effects other than just seeing the chart refreshing more rapidly. I'm also assuming that if I just call ChartControl.Refresh() in OnMarketData() with the following check:

if (e.MarketDataType == MarketDataType.Last)

and without any checking for a time delay, then it will just update on every tick, equivalent to setting the DisplayUpdateInterval value to 0 in NT 6.5.... right?

(If this works as I think it would, then I would be pretty happy, because I could make NT function properly for me.)

EDIT: Never mind on some of this stuff, I just noticed a post below that answered some of these questions. If I have made any errors in what I said above, however, please correct me.

[bobbethgoo]

So in my case, having an artificial .5 second delay is ridiculous, because my system can easily handle the data refreshing at 100 ms. The fact that yours can't doesn't mean that other people like me should be limited.



Well said, strongly agree.

[mmtrader]

Support,

I suggest the following way to implement this feature,so that it is configurable by users

* Use a chart update policy and let users define multiple policies.
* On daily charts, for example if one has 30 charts open and 10 of them are daily charts, one can use the policy to update the daily chart once every 5 minutes.
* When a workspace is opened but not active, have a user configurable override option for non active workspace. So, that if there are like 5 workspaces(each with like 10 charts or so) , when the corresponding "workspace override update variable" is not enabled and set to 5 mins, the non active workspace only gets updated every 5 mins instead of very 0.5 seconds. This saves cpu/ram resources for non active workspaces.


So, I suggest there be three levels of system variables. one as global policy, one for "non active workspace" override,..so that every workspace has such a variable, and one for every chart. Also,if there is a way to define the same set of variables for processing every tick or not for global-policy/workspace/chart,it would be great. So, basically two sets of configurable variables,one for chart UI updating and another for chart processing every tick or not.


The idea is to save system resources and provide user configurable options. So, that experienced users who need several workspaces/charts trading multiple instruments can configure them appropriately. This would also solve the multiple workspaces problem. In nt 6.5, ninja would crash if one opens 5 workspaces each with 10 charts.

--
mmtrader