Performance/refresh issue

Discuss possible software enhancements/changes here.

Moderator: Matt

Post Reply
RomChip200
Posts: 384
Joined: Mon May 11, 2009 7:58 pm
Location: FRANCE

Performance/refresh issue

Post by RomChip200 » Tue May 31, 2016 7:14 pm

I worked a lot with 1.2.18 version (since 2015) on my ultra notebook Atom 1.2Ghz embbeded in my 300zx and just updated to 1.2.58 to be a bit more up-to-date.

I don't know when it really changed b/w 1.2.18 and 1.2.58 but with 1.2.58, I have huge performance issue that makes this version barely usable.
Once connected with Consult in Stream mode and double Innovate wideband, I cannot switch b/w the windows (I just have Consult raw values window,record log window and widebands values window opened), start a record, buttons don't respond.
I'm obliged to stop the engine to force disconnection from Consult and widebands to be able to stop the record and effectively save the log to the disk.

It's a major issue.
I got the feeling you added so many patches b/w these 2 versions to circumvent corner cases that at the end, the sw is no more "optimized".

Is it the same trouble than this one ?
http://www.nistune.com/mantis/view.php?id=161

RomChip200
Posts: 384
Joined: Mon May 11, 2009 7:58 pm
Location: FRANCE

Re: Performance/refresh issue

Post by RomChip200 » Tue May 31, 2016 7:22 pm

I just noticed I also used the 1.2.32 version for a while, so for the moment, I revert back to this version.

Matt
Site Admin
Posts: 8432
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Performance/refresh issue

Post by Matt » Wed Jun 01, 2016 10:46 am

That is the issue. I think it is to do with data update > display update rates

Each data update is processed and then passed to gauges, logger, map trace cursor, map highlighting etc.

Stream mode significantly increases data updates, so I have to reduce the display refresh rate to fix this issue

Matt
Site Admin
Posts: 8432
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Performance/refresh issue

Post by Matt » Thu Sep 28, 2017 4:49 pm


RomChip200
Posts: 384
Joined: Mon May 11, 2009 7:58 pm
Location: FRANCE

Re: Performance/refresh issue

Post by RomChip200 » Thu Sep 28, 2017 8:39 pm

Hum, a 2 years-old issue ...

I'm currently using the 1.2.76 and lags are quite usual:
1) when initiating Consult or widebands connection, it only responds after 10-15 seconds
2) when switching from one window to another, typically when the gauges panel is opened in foreground and log record is done in background.

Sometimes, it is followed by a complete Nistune crash ...
I perform some logs on a daily basis, so it doesn't make my life easier.

You could also update only the windows opened/maximized, if not already done like this.

Matt
Site Admin
Posts: 8432
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Performance/refresh issue

Post by Matt » Fri Sep 29, 2017 1:12 pm

63 open issues or enhancements currently open, plus many phone calls, emails, install ECUs, repair ECUs, fit boards daily and only myself. I work on what I can based on priority. Things like crashes, or firmware problems are higher issues so get resolved first

RomChip200
Posts: 384
Joined: Mon May 11, 2009 7:58 pm
Location: FRANCE

Re: Performance/refresh issue

Post by RomChip200 » Fri Sep 29, 2017 8:21 pm

A 2 years-old issue ... meaning we have to live with that.

I'm more interested (Maybe I'm the only one :roll: ) in daily overall stability and reliability rather than adding features that have snowball effects and side-effects and are prone to trigger crashes.
You can argue Nistune increased in complexity across the years but the report is the basic features have been affected by the enhanced features and versions 0.9.x worked better than the latest 1.2.x flavors.
Making too complex denature the initial purpose.

Is Nistune mono-threaded or multi-threaded ?
Having a scrolling bar refreshing at high speed below the Consult and lambda sensors connection buttons to highlight it's alive is just too much costly.
A red/green bullet would be enough.
All of this to say the overall GUI should be rationalized. Making a user friendly GUI is a full time job.

Matt
Site Admin
Posts: 8432
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Performance/refresh issue

Post by Matt » Sat Sep 30, 2017 6:48 pm

A 2 years-old issue ... meaning we have to live with that.
Not necessarily. Its not a noted an issue on newer laptops, so is lower in priority than other issues, also more difficult to resolve. However I do intend to fix this still (otherwise I would have just closed it). It has not been at the top of my attention list however.

In other words on the various machines I have here (including my 7 year old Dell laptop) I dont see it but it is a problem on some PCs where the updates to the graphics are too much for the processing to handle. That becomes more of a tricky problem to solve where it only happens on the older laptop but development environment exists done on the faster machine. Higher updating inputs (like consult in stream mode + DLP at 115200 bps will tend to cause the most processing updates on a machine)
I'm more interested (Maybe I'm the only one :roll: ) in daily overall stability and reliability rather than adding features that have snowball effects and side-effects and are prone to trigger crashes.
If you can report what triggers the crash, I can use that information to narrow down the causes of it. I also have the crash logs to work through, but if you are running older versions, I will not look at crash logs from those older versions (only the newer versions)
You can argue Nistune increased in complexity across the years but the report is the basic features have been affected by the enhanced features and versions 0.9.x worked better than the latest 1.2.x flavors.
The only extra complexity has been added in the feature pack processing for those ECUs that use it. Don't under estimate the number of requests that come from these forums, other tuners and individuals. There was a rewrite from the fixed wideband sensors and consult tables to a combined sensor design done to the 1.x versions which is more for back end stability and maintainability. I get you might not understand the complexity of things in the background, but I am working to resolve issues which cause problems. Yes I agree that new features can sometimes generate new bugs
Is Nistune mono-threaded or multi-threaded ?
Of course its multithreaded. Each serial device spawns of its own thread and passes the information back to now a single main store for wideband and consult data. That data is then used by the maptracing, logging and general gauge display functions. Thread protection is required to ensure that updates of each data item are made when another item is not using it. Some crashes have previously happened during disconnect of data during an update for example, very difficult to repeat and find.
Having a scrolling bar refreshing at high speed below the Consult and lambda sensors connection buttons to highlight it's alive is just too much costly.
Not really, removing the bar will not make much difference to overall processing time as its just a gradiant overrrideen progress bar update done from a thread.
All of this to say the overall GUI should be rationalized. Making a user friendly GUI is a full time job
Yes and there are a lot more things I would like to add, but will to fix these initial issues firstly. Note adding extra features, attracts more customers which keeps income to keep working on this.

Post Reply