System unresponsive during image integration

[georg.viehoever]

Hi,

while running image integration, my Windows system essentially comes to a halt. I cannot read mail or surf the internet. Is this due to the fact the compute threads in PI run in high priority? If this is so: It would be polite to run compute threads in low priority, so that interactive operation is not stopped. While running in low priority usually costs a few percent of performance, it would be polite not to stop interactive use. Maybe the compute thread priority can be made configurable in the preferences dialog?

Georg

[Nocturnal]

It is configurable in the properties

I think priority 7 is not the correct default setting. I'd rather wait a few percent longer while being able to listen to music or surf the net than the other way around. This makes PI look like a bad citizen.

[georg.viehoever]

Sander,

thanks for telling me about this default. I agree, default priority should be below interactive priority - even a the cost of some performance points.


Georg

[Nocturnal]

Cool. I'm sure Juan will come around and tell us about the virtues of turning a multi tasking machine into a single purpose box

[Juan Conejero]

I'm sure Juan will come around and tell us about the virtues of turning a multi tasking machine into a single purpose box

You know me well

OK, you've convinced me. In PI 1.5.3 for Windows, the default maximum thread priority will be 6 (highest) instead of 7 (real-time). I think this should fix all practical problems. For Linux and Mac OS X it will continue being 7, since the thread scheduling policies in these OSs are quite different and I haven't seen these issues (unless some users tell us the contrary).

[Nocturnal]

Excellent!  When I have some long running processes I'll do an execution time comparison between 7 and 6. As long as the machine is basically idle besides PI and maybe Winamp and some light browsing I expect the difference to be negligible.

[Nocturnal]

Code: [Select]

ACDNR: Processing view: M51_HS_proc
Writing swap files...
65.11 MB/s
In-place color space conversion: 100%
Building luminance mask: 100%
Processing CIE a component: 100%
Processing CIE b component: 100%
Processing luminance: 100%
In-place color space conversion: 100%
16.250 s

Preferences: Global context
0.016 s

ACDNR: Processing view: M51_HS_proc
In-place color space conversion: 100%
Building luminance mask: 100%
Processing CIE a component: 100%
Processing CIE b component: 100%
Processing luminance: 100%
In-place color space conversion: 100%
16.234 s

Not sure if ACDNR is a good example but as you can see there's no appreciable difference between 7 and 6 in this case although I left the system alone at that point. I guess that shows there is no cost to leaving priority at 6. Every cycle you steal from PI by doing other things will cause the process to finish a bit later but if you want it quick-quick-quick then simply leave the box alone and it'll be as fast as possible.

[georg.viehoever]

Juan,

to add some additional data: I did a HDRWavelet transform of a Canon CR2 picture on my Core2 Duo dual core laptop running Vista with different thread priorities. The usual baclground load on this system by virus scanners, task manager etc. is 5-10% :

Prio 7: 50.3 secs (system completeley unresponsive)
Prio 6: 50.9 secs
Prio 2: 52.9 secs (was able to write this message concurrently)
Prio 2, 1 CPU only: 80.1 secs

Personally, I think the lowest priority that does not endanger PI stability is the correct setting for compute intense threads. Almost any other action (e.g. GUI, virus scanner, internet, ...)  should have higher priority than a compute process. Plus: I dont see why a low compute priority should be dangerous to PI stability, as suggested by the tooltip.

Just my 2 cents on this.

Georg

[David Serrano]

There is also a psychological effect in this: 5 minutes waiting for a process are actually longer than 6 minutes listening to music!

Juan: haven't noticed any slowdown during my PI usage, so prio 7 is just fine on Linux.

[georg.viehoever]

There is also a psychological effect in this: 5 minutes waiting for a process are actually longer than 6 minutes listening to music

Is this a feature request for animated multi-media progress bars?  Just joking....

Georg

[Juan Conejero]

Hi again and thanks for your suggestions and insights on this important topic.

I think I have come to a good solution for this problem. Instead of limiting the maximum thread priority, all processing modules use now a platform-independent default maximum priority. Under Linux and Mac OS X, the default maximum priority is real-time (7). Under Windows, it is highest (6). This difference is due to the default thread scheduling policies used by the different operating systems.

So in PixInsight 1.5.5 (now you're asking where's 1.5.3 and 1.5.4 8) ) the default maximum priority remains 7, and it is the responsibility of processing modules to use the default maximum priority, which is defined in the standard pcl/Thread.h header in a portable way. There are no more "freezing" problems on Windows and all modules share a unique source code base, without additional "#ifdef __PCL_WINDOWS" constructs.