Nistune Forums

Think there may be performance issues with your Atom laptop. You are the only person who has raised this with me. As Eric mentioned, we still have older XP laptops running the software fine....

However I have noted on my older netbook that stream mode with too many windows open can hang the software (until disconnect, when all the consult message updates stopped). I know what the problem is (too many messages from stream mode) but coming up with a solution is a bit more complicated. It is still an open issue, but my current machines don't hang (including my 10 year old Dell)

As there have been additional items added (more gauges, maptrace events etc) this means more messages passed around (especially stream mode).

OK with tablet mode, it solves one problem.

Good I can tick that off

Of course, Auto-open gauges is disabled, this is not my troubles.

ok thought it was.

1) Design (e.g window location once minimized, buttons, panels location, ...)

Windows go to the bottom left corner. That's what MFC does by default. Is your bottom corner hidden? Can you see the status panel? Windows > Cascade can get back hidden windows

2) Performance: this item is getting worse and worse. 1.2.87 perf behavior is worse than 1.2.78.

One Consult is connected, Nistune becomes sluggish, windows cannot be moved or closed.

In stream mode, or tuner mode or both? Not sure why 1.2.87 is worse than 1.2.78. I've not changed the consult data streams between versions (will need to check change log). Recent updates are now parsing XML but that only happens on change of address files.

Once the connection is dropped by switching ignition key off, sometimes Nistune reacts after 1 minute and gives you the hand back, sometimes, I have to disconnect USB hub, sometimes Nistune crashes, soemtimes I have to kill process and restart.

Crashes when pulling the plug can be the consult cable driver (especially if BSOD). Disconnect the grey plug and it will stop the data. The reason as before is there is too much processing of data for the PC to handle. What needs to happen for your Atom to catch up is start dropping more messages (ie consult data updates) so the display can keep up with it. If the onboard graphics is shite then screen cannot update fast enough to the messages and the backend gets frozen up.

Machine: Atom 8350, 2GB RAM, 1920x1080, win10

Probably runs shared graphics memory?

Windows 10 - Is 2gb of RAM enough?
Get at least 4GB of RAM. That's "four gigabytes of memory" for those who don't speak PC. Anything less and your system will run like molasses--something to keep in mind as Black Friday deals roll around. Many "doorbuster" laptops will have only 2GB of RAM, and that's just not enough.

Windows 10 uses so much more resources than earlier OS's which is why applications pushing through more messages get bogged. Add wideband data (two input sources) on top of consult data and it gets very busy.

Let me give you key use cases:

_Consult is connected
1) UC1
_Consult regs window cannot be moved or closed anymore (only ignition off will solve it sometimes)
_Consult gauges window is minimized but unreacheable (hidden by left pane)

If the guages window is not open, does the regs window freeze up still? Trying to work out if that is contributing?

2) UC2
_Consult is connected
_Consult gauges window is opened, not maximized (because if so, the window buttons are so small ...), but the window cannot be closed or moved, 2/3 are displayed only (problem of refresh), the sizes of the rectangles are not all the same (don't ask me why ...)
_again ignition off will solve it sometimes to get back control of Nistune

Okay so just guages window will update too fast and freeze up? But only stream mode?

Just to clarify I still have the problem open to look into but I'm rewriting a bunch of the gauges at the moment, so there will be NEW customisable guages. At the moment the write click context menu has been added, and the different types are being designed

There is no point wasting time fixing the older ones out when I'm going to throw the code away. However I will optimise the message rates but monitoring messages IN/OUT and dropping them if I need to do the display can keep up without freezing the scheduler up (which sends the messages)

You cannot ask me (and people) to use a given laptop with XP or Win7.
My cables are USB genuine FTDI cables. I don't use Consult grey cable. I have my own Consult interface with SUBD9 output.
Tablets with Win10 are there and it should work with.
Atom 8350 with 2GB works very well, boots fast and mine works in 64bits mode. By experience, I can tell you it's not only my machine
and telling win10 requires 4GB RAM min. is a shortcut that may be valid for desk machines.

I have no problems with other apps as Conzult, Nissan Datascan I use for other purposes, so what ?
I mainly use Nistune because it allows me to log the widebands in parallel of Consult infos.
I carefully follow the Nistune releases, and it's a kind of hit and miss across the releases and the reworks you perform. This is really frustrating.

I highly suggest you to perform non-regression tests on this kind of platform too, aka Win10 tablets, you may discover some hidden bugs.

I'm not drunk, this is on my desktop PC:

Rectangles in the gauges window have not all the same size (so gauges will not have the same size once connected)
Once minimized, the gauges window cannot be reached, the left bottom pane hides it. The left panes are not real windows and cannot be moved.

You cannot ask me (and people) to use a given laptop with XP or Win7.

I am not asking that.... where did I say that?

Atom 8350 with 2GB works very well, boots fast and mine works in 64bits mode. By experience, I can tell you it's not only my machine
and telling win10 requires 4GB RAM min. is a shortcut that may be valid for desk machines.

So I googled running Win10 on 2GB RAM and that is the minimum recommended, the overall recommendation was to run more RAM (eg 4GB or higher) since Win10 is more resource intensive. Disagree with that if you want, but just what I found

My cables are USB genuine FTDI cables.

FTDI drivers have a bug when you pull the cable whilst the port is open. It can crash the caller or BSOD. I've seen it do it whilst running in the debugger

Tablets with Win10 are there and it should work with.

As I said already. I've got an open problem report on this issue, so am looking at it

I have no problems with other apps as Conzult, Nissan Datascan I use for other purposes, so what ?

Those programs only update one or two displays, not loggers, maptracing, sensor tracing, wideband all combined together. That is the difference

I carefully follow the Nistune releases, and it's a kind of hit and miss across the releases and the reworks you perform. This is really frustrating.

When I do updates to the software in the BETA versions, there may be potentially new introduced bugs from adding new functionality to the software. If you have the problems with the latest BETA then go back to the previous version or January stable release.

I highly suggest you to perform non-regression tests on this kind of platform too, aka Win10 tablets, you may discover some hidden bugs.

BETA releases are not completely regression tested, and I only make BETA into a full release once I have done in depth testing, and know most of the open bugs (in my problem report list) have been resolved after doing updates. Pushing a release quickly out like yesterday, does not give me time to run full testing over every single function and corner case. The problem was not specifically tablets but the windows tablet mode. There are many permutations of hardware differences. Anyway will see what I can do with the display

All the problems you have raised in this thread are not introduced in the BETA versions of recent, but preexisting problems. The only exception is the freezing up due to display updates.

So you have raised two NEW issues from this post
1. Consult multi view Frame size not even. At this time not sure why the gauge display shows different size frame. Will be a separate low priority issue:
http://www.nistune.com/mantis/view.php?id=207

2. Some of Minimised windows positioned on lower panel, hidden by LHS parameter list. Default windows functionality is to put them at the bottom, however my parameter list is hiding them. Workaround (Window > Tile) to get them back.

See what I can do to relocate the minimised windows on the RHS instead of LHS
http://www.nistune.com/mantis/view.php?id=208
So we have three issues (one minor) and the other two (data freeze up, and minimised windows cannot be seen) at this time?

You never answered my question if the freeze up is only stream mode?

Even frame problem fixed. Minimize window different story. Was going to shift to RHS with half day investigating it so far. See if I can put it to front but that will cover params which is not ideal. Can seem to somewhat control maximum size but not position (so far, still looking into it). If no luck will kill max button!!

I'm sorry to bring some problems in a messy order. This is an emotive part in this.

Well, when you say
Those programs only update one or two displays, not loggers, maptracing, sensor tracing, wideband all combined together. That is the difference
you distort a bit the current perf problem.

The current perf problem only involves Consult connection and gauges panel that never gets refreshed, window cannot be moved , bla bla ...

Effectively I use it 100% of the time in stream mode. Btw, once you hit the button to record a log, Nistune disconnects Consult and switch back in stream mode.
So, I did a test this morning in Tuner mode with Gauges panel only. In this case, you can effectively still move the window but each gauge is refreshed every 1-2 seconds randomly, just useless for tuning purposes, lol.

So, it means you definitively have a problem in the handling of Consult data stream as it affects the overall behavior of Nistune. And why is it so slow in Tuner mode ????
It should be pretty bad b/c if you compare with Conzult panel below, it does the same than your gauges panel but with bargraphs and I can tell you the RPM or injector pulse are typically refreshed every 100ms, so basically Conzult manages to so domething Nistune doesn't in the gauges panel.... In my job, we say " the problem is b/w the chair and the keyboard" i.e. the developer
UC3: missing gauges never get displayed after a while in stream mode
UC4: gauges panel control buttons are unreacheable

So, seems the Consult data stream is the culprit.
You should take a step back, revisit its management, make the left panes moveable and revisit the gauges window behavior.
I cannot believe the Consult data stream is so cpu consuming, there' should be something wrong in your design, this is only 9600 bauds and few bytes stream , nineties stuff lol and Conzult does the job ...

This is an emotive part in this.

Yeah I can tell

So, I did a test this morning in Tuner mode with Gauges panel only. In this case, you can effectively still move the window but each gauge is refreshed every 1-2 seconds randomly, just useless for tuning purposes, lol.

On that laptop yes. Got an idea for a solution, as I said already

And why is it so slow in Tuner mode ????

Tuner mode does a memory read with equivalent of 0xc9 commands for each memory address, and combines those with direct reads for DTC codes, knock flags, dwell time, write and read data cells. Basically we are multiplexing a whole lot of data over 9600bps to allow tuning and changes at the same time

so basically Conzult manages to so domething Nistune doesn't in the gauges panel....

Nistune would run the same if I removed all other display updates and just did one set of gauges

You should take a step back, revisit its management

Thanks for the tip.... the management is fine. Its the scheduler which needs fixing. Details in my CR:
http://www.nistune.com/mantis/view.php?id=161

make the left panes moveable

Those are staying where they are. There is no need for another 'movable window'. I've fixed the code tonight to make all minimised windows stay to the right of this. Also there was another issue with closing a window in minimised state saving the 'minimised position' when closed. so that has been rectified. About ~15 windows needed code updated for those changes

revisit the gauges window behavior.

The guages are fine, its the scheduler which needs updating as for this. MFC uses sync or async calls. The caller cannot wait for the display to finish updating, so sends messages to each window. As mentioned before, there are too many messages on your machine and it locks up. I'll monitor messages sent and will not send the next one until processing is done. That is the plan

Nistune would run the same if I removed all other display updates and just did one set of gauges

Just refresh the window(s) that are in the foreground. If the window is hidden by another window, don't refresh it.

there are too many messages on your machine and it locks up

but Conzult doesn't lock up, Idon't know if it uses 0xC9 command or stream mode, but in all cases, it works.
You may admit there's something wrong in your Consult data stream management, too much memory allocation, memory copies, pass data instead of pointers, I dunno, but there's something. Is Nistune in C++ ?

I'll monitor messages sent and will not send the next one until processing is done. That is the plan

I get the feeling it's going to be dramatic in term of user experience.
Add an option in the conf panel to set the refresh rate, I may beta test it.

What I'm planning on will only send messages to those responding (ie those in foreground). Conzult only updates one display panel as I said already (repeating myself )

Data is saved from USB consult, Consult1 and Consult2 into a central store. It's converted and saved into log format, display format etc, and then maptracing coordinates calculated etc. After that the scheduler pushes the updates out to each window. Thats the bit thats need updating. Refresh rates wont be affected, so you don't need to worry about that

It's converted and saved into log format, display format etc, and then maptracing coordinates calculated etc

But you don't need to do all of this to only update only the gauges panel if only this one is opened. It was my point.

I may conceive Nistune slows down when you are using more and more features as maptracing in parallel of log recording with Consult raw registers window opened too.
But here, I'm speaking about a basic UC, gauges panel opened only, Consult connected.
If really you perform by default all the processing you mention just above, this is inefficient. No need to convert to log format if log record is not ongoing ...

I don't catch your position. I have the feeling to underline some evidences in term of SW or GUI behavior but you keep telling me "Nistune does a lot of things in parallel because it's very powerful and so, all processings are required upstream, I cannot avoid them, bla bla, this is the way Nistune is shaped ... and it is well designed so, there's nothing to change. Change your laptop."
I stay on my position, Conzult does the same than your gauges panel when only this one is opened in Nistune, so it should behave the same in term of user experience.

Repeatable on slower netboooks

Not repeatable on Inspiron 6400. Need to borrow netbook

Inspiron 6400 has Intel Core2 Duo T7200

http://cpuboss.com/cpus/Intel-Core2-Duo ... 5-x5-Z8300

GeekBench 3 (AES single core)
Data courtesy Primate Labs
Core2 Duo T7200
80,800 MB/s
Atom x5 x5-Z8300
279,050 MB/s

Dell has a dedicated graphics card (makes a big difference). However windows 10 is way more resource intensive. If I could put windows 10 on that laptop, it would struggle. Got access to another netbook so will test that before I put up changes

If I could put windows 10 on that laptop, it would struggle.

Be not so sure. Win10 is close to win7 behavior.

My Asus G53J went from Win7 to Win8 to Win10. These were updates rather than reinstall and all apps got slower (loading, refreshing etc) with each upgrade. Particularly with Windows 10. Did a whole wipe/reinstall which made it a bit better