bugs in Git tree

[djandruczyk]

git pull... Ahhhh....
____Much____ mo betta, no more crashes, but ditto on the update issues, much slower than before (when it connected before)
MTX was frozen almost solid on the old refresh settings, took a minute or 2 to swicth tabs so I could drop it to 5 fps from the defaults.
(once I figured out it wasn't just hung)

Updates were quite speedy before, now... not so much.
Comm seems much more reliable, getting the right strings in the id fields, always.

PentiumM @ a scorching 1.8 GHz, 2G RAM, in a Gobook3 (with a real live serial port, main selection criteria for the machine)
Mandriva 2010.1. (also works under 2010.0)

Screen is 1024x768, 9250M ATI chip for graphics, so it can do OpenGL in hardware if you don't do more than Q3 or Alien Arena on low settings.
(Hey---CPU, resolution and 12" screen bigger than the disposable Netbooks folks use for MS tuning, and I can drop it on concrete from 4', repeatedly. I tested that spec once unintentionally... While running. No damage other than a paint chip on the concrete and to my shorts.)

Now I just have to look for your instructions how to manually reduce the GTK fonts, it doesn't obey the KDE settings like GTK apps are supposed to...
(everything else GTK that ships with the system does, there must be a missing hook)

OK, I pushed up another fix which should GREATLY improve the responsiveness. Turns out the gui side was getting behind the serial side (they are decoupled from each other), so I put in some checks to see if the gui side is "backed up", if so it automatically reduces the serial polling rate in order not to bury itself. I found this allowed me to set max polling rate on the comms tab (10 ms between polls), and the gui remained very responsive when changing values unlike previously where for me it was taking from 5-15 seconds to show the changes. the side effect of this is the serial polling rate isn't necessarily as fast as you'd think it is.

[mahler]

...

What speed is your computer, and does it have more than 1 core or not?

Turn down the polling and update rates on the comms tab, which should improve responsiveness.
i.e. INCREASE the delay between reads and/or decrease the FPS rates for the sliders/ttext/dash or 3D display(s)

I have got a 2.20 GHz Intel dual core on a ThinkPad T61.

I tinkered with the communications settings and that fixed the responsiveness.
Communications -> ECU Runtime Variable Settings

original settings (high latency):
Delay between reads (ms): 20
Runtime Sliders update rate (FPS): 20
Runtime Text update rate (FPS): 15
Dashboard update rate (FPS): 25
3D Display/VEtable update rate (FPS): 15

improved settings:
Delay between reads (ms): 60
Runtime Sliders update rate (FPS): 10
Runtime Text update rate (FPS): 10
Dashboard update rate (FPS): 10
3D Display/VEtable update rate (FPS): 10

This is without your latest update. I will try that as well and let you know of any difference.

[mahler]

...

OK, I pushed up another fix which should GREATLY improve the responsiveness. Turns out the gui side was getting behind the serial side (they are decoupled from each other), so I put in some checks to see if the gui side is "backed up", if so it automatically reduces the serial polling rate in order not to bury itself. I found this allowed me to set max polling rate on the comms tab (10 ms between polls), and the gui remained very responsive when changing values unlike previously where for me it was taking from 5-15 seconds to show the changes. the side effect of this is the serial polling rate isn't necessarily as fast as you'd think it is.

That change helped too. Even with the original communication settings that had high latency before the responsiveness is good.

[djandruczyk]

I'm still messing around with this. I added two feedback entries on the comms/runtime tab (PF Queue Depth and Gui Queue Depth). As long as those are below 10, everything should be fine and dandy, above that the gui will get sluggish and serial reduction rate will kick in to throttle the serial stuff as the handlers running are taking too long and beginning to stack up. If either is above 8-10, it would be wise to increase the time between serial polls. I find on my machine that throttling kicks in at about 26ms between polls, so anything higher than that and things are fine.

[djandruczyk]

I put in some more incremental improvements. Mtx will auto-throttle if the PF Queue goes over 15, and the counter will go red, saying you SHOULD increase the delay between serial polls.

I recommend to pull and rebuild/reinstall

Thanks!

[djandruczyk]

Another big round of fixes for interactive response.. Lots of work, and experiementation done to improve the responsiveness. Please do a

Code: Select all

git pull ; ./autogen.sh  ; make clean ; make ; sudo make install

and report back...

[djandruczyk]

0.9.22 has been released, See my signature below for urls and instructions.