Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000253TunixFreeEMS Pluginpublic2011-08-29 02:422012-03-30 20:44
ReporterFred 
Assigned Todandruczyk 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000253: RT Variables are NOT updated when two 3d table views are open!!
Descriptionhttp://stuff.fredcooke.com/mtx.3d.two.of.high.fps.high.cpu.no.rtv.updates.png [^]
http://stuff.fredcooke.com/mtx.3d.one.of.low.fps.low.cpu.normal.rtv.updates.png [^]

Higher FPS probably due to having less to do...
TagsNo tags attached.
FirmwareVersionunknown, updating issue to appear in roadmap
Attached Files

- Relationships

-  Notes
(0000245)
dandruczyk (viewer)
2011-08-29 02:57

This is due to your S L O W machine. turn down the polling rate, and or the 3D window update rate or get a faster machine.

Or, gasp, get out a profiler (gprof,cachegrind/etc) and make it faster and submit a patch.
User avatar (0000246)
Fred (administrator)
2011-08-29 02:59

Wait, MTX detects my load average and then stops requesting all RT data packets to try to reduce load? That's AWESOME, Dave :-)

(Re-read the title)
(0000247)
dandruczyk (viewer)
2011-08-29 11:40

No, MTX sees the IO queues are backed up due to other tasks taking up too and to avoid bringing the machine to it's knees it starts dropping requests in order to self-throttle instead of crushing the machine straight into the ground.

If you went and looked at the COMMS or Runtime tab and noted the PF queue depth or Gui Queue depth values, you'd probably see the number consistently higher than ZERO. This means your S L O W machine is taking way too long to do something important like update a 3D OpenGL with a software renderer and that it is blocking something else from running. With EVERY gui toolkit out there, ONLY ONE THREAD can update the gui, so requests to do gui operation must be serialized in some form or another. MegaTunix does this via the PF queue and the Gui queue. (PF queue is the "PostFunction queue" and takes care of high-priority must run ASAP stuff that deals with the gui After a threaded I/O operation.) the Gui queue is for low priority gui updates, and handling of messages passes from other thread contexts, so that they execute under the gui thread, otherwise the system will deadlock or crash if another thread does a Gui operation.
User avatar (0000248)
Fred (administrator)
2011-08-29 19:08

OK, I understand.

Something in your threading model is not healthy in that case, though.

If the queue stops growing (no packets requested) and ANY get processed, it will shrink, and eventually allow more requests for data to be sent. But it doesn't. It sits not requesting data forever. That is broken in my eyes. The point of threads is to run interleaved and in parallel, and that's clearly not happening here, or some logic is preventing them from doing as they should.

There is an opportunity here for an architectural improvement in the threading area, I hope that we find it :-)
(0000249)
dandruczyk (viewer)
2011-08-29 21:56

How do you KNOW it stopped requesting? Did you stick your logic analyzer on the serial port and see requests stop coming? Since the communications have to be serialized there's not a whole lot that can be improved. Serial runs independantly of the gui thread, however the feeder to the serial thread MONITORS the gui thread depth and throttles back when things get slow/sluggish. I have NOT been able to induce a "full stop" without recovery, if the pf depth grows too high, I reduce the runtime text/sliders or ve3d update rates, or the serial polling rate, and the pf depth falls, which is the intended behavior. Give me a sequence that'll induce the supposed failure you see, as your original report does NOT do it on my end on either the mac or my PC.
(0000250)
dandruczyk (viewer)
2011-08-30 01:18

Pushed a very nasty potential fix. Though it's likely to cause deadlocks on Windows, and possibly Mac OS-X. TEST IT
User avatar (0000257)
Fred (administrator)
2011-09-09 09:44

This was fixed some time ago! Thanks dave, you're a legend (in your own time/awesome/etc)!
User avatar (0000259)
Fred (administrator)
2011-09-09 14:10

Reoppening, fix reverted. New fix being researched.
(0000260)
dandruczyk (viewer)
2011-09-15 00:27

New fix completed, closing
(0000261)
dandruczyk (viewer)
2011-09-15 00:27

Fixed
User avatar (0000262)
Fred (administrator)
2011-09-15 11:03

Testing 3d display and closing them, something bad happens every time, one or the other type of failure, either hang or crash. One of each captured for you.

http://pastebin.com/UqZFfhEn [^]

Everything works great until i try to close any 3d window.
User avatar (0000263)
Fred (administrator)
2011-09-15 11:04

Re-opening as I feel the above symptoms are related to this work.
(0000267)
dandruczyk (viewer)
2011-09-15 12:24

Are u closi g via the close button or via killing the wimdow via the wimdow manager close symbol . Context is important!!!
User avatar (0000269)
Fred (administrator)
2011-09-15 12:31

I was using the window manager close symbol, however I just tried with the close button (which I didn't even see before, isn't that a bit superfluous? I'd remove it. Or at the very least give it the exact same code path.) and it behaved the same way. Hope that helps. Please try to remember that context is something only the person with the intimate knowledge can see. That's what this medium is for, requesting more specific info from the reporter after initial report.
(0000270)
dandruczyk (viewer)
2011-09-15 14:03

Solved commit 4bf6914bf27deae543b2aedd97df96c27ab11ae9
(0000271)
dandruczyk (viewer)
2011-09-15 14:03

commit 4bf6914bf27deae543b2aedd97df96c27ab11ae9
User avatar (0000272)
Fred (administrator)
2011-09-15 14:17

Tested, works flawlessly now :-)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker