BYE v3.1.0 rc5 is very Heavy CPU while performing an Image Exposure

[s3igell]

I image with a rather well-endowed Intel i5-Core2 Laptop.  I also run PHD2 and a few other Apps - sometimes even stacking while Imaging with DSS-Live.  I almost always have TaskManager and ResourceManager open in the background to monitor CPU usage.

 

In any case, on a rather regular basis I've confirmed that BYE is reported as keeping one CPU Core BUSY while performing little but the mid-Exposure Countdown.

 

I also sometimes Image with an older and weaker AMD-based Laptop, and see the same thing.  I even pestered another Imager at our Dark Site to run TaskManager on his Sony VIAO, just to see the same behavior.

 

While doing some PHD2 Simulation Testing and some Dark Library Additions on my Home Workstation - a very well-endowed i5-Core2 Quad-Core with 16GB and multi-RAID5s - I watched the very same pattern of an entire CPU Core being 100% Busy by an instance of BYE v3.1.0 rc5 during the middle of an Exposure.

 

I decided to test additional scenarios and capture Screenshots:

Single Instance Bulb Exposure - 100% Core

Single Instance Bulb Preview - 100% Core

Single Instance Bulb Exposure with Guiding - 100% Core

Single Instance Tv Shutter Exposure - 40-60% Core

Single Instance TV Shutter Preview - 40-60% Core

Dual Instance Bulb Exposure - 100% of 2 Cores

Dual Instance Bulb Exposure with Guiding - 100% of 2 Cores

Dual Instance while Dithering - 0-5% of 2 Cores

Dual Instance while Background Worker - 10-15% of 2 Cores with Worker also 20-25% of 2 Cores

Single Instance Frame&Focus Bulb Snapshot - 100% Core

Single Instance Frame&Focus Bulb LiveView - 20-25% Core

Single Instance Frame&Focus Bulb Paused - 0% Core

Single Instance Planetary Bulb 5x LiveView Capture - 20-25% Core

Single Instance Drift Bulb Drifting - 25-30% Core

 

 

It seems like the BYE "Bulb Exposure Timer" (or it's SDK Component) is the Culprit.  Any time that a Bulb Exposure - Image or Preview or Snapshot - is underway then the CPU Usage of that Core (Process or Thread) is Maximized.

Could it be that the Main Process is Polling the SDK for the "Finished" Event in a Loop that is Too Aggressive (too few wait/pause/release calls - don't know .Net terminology) ??

 

I posted a rather similar Thread back on the old BYEOS Yahoo Group, based on BYE v2.0.x, and have observed the same actions while using v3.0.3.  I don't think this is a NEW Issue, and cannot find anything outside the BYE App that is at fault.

 

Some screen shots attached, others sent via email:

  

 

 

Please review and advise. 

[s3igell]

Notice that I can prove that Dual Instances of BYE v3.1.0 rc5 can perform Dithering of Dual Instances of PHD2 v2.3.1 on a single PC !!

 

(Notice that each PHD2 Guider Graph shows a "Di"ther has just started...  AND each BYE has its "OTelescope.BackgroundWorker" Thread busy...  And it all consumes only about 50% of one i5 Core!!)

 

[admin]

This is not the SDK, it is BYE.

 

It can be 1 of 2 things.  The progress wheel update OR the spin timer waiting for bulb to end.

 

Disable the progress wheel and see if it makes a difference.  Goto settings -> advance settings and set the progress to blink instead.  Does it make a difference?

 

If not I'll send you a fix for the spin timer waiting for bulb to end.  I guessing this is the actual culprit.

 

Regards,

 

 

[s3igell]

Setting the Progress to "Blink" in the Advanced Settings made no change - still 100% usage of the Core running BYE.

 

I tested both a Bulb Exposure in Imaging and a Bulb Snapshot in Frame&Focus.

[admin]

Take a TV picture, say 30 seconds, do you still get 100% during the exposure?

[admin]

Is the the backgroundworker process that is taking 100% or the UI process?

[s3igell]

Is the the backgroundworker process that is taking 100% or the UI process?

As displayed in the TaskManager featured in the lower-left of each Screenshot, it is the "BinaryRivers.BackyardEOS.Start.Camera1.exe *32" process ascribed as using "25%" (of a 4-Core CPU).  The "OTelescope.BackgroundWorker.Start.exe *32" process only makes its presence known (at moderate CPU usage) when an Image is being Processed after Download - never found to max out a Core.

[s3igell]

Take a TV picture, say 30 seconds, do you still get 100% during the exposure?

 

No, Tv Exposures do not produce as heavy a CPU load.  The last of the embedded Screenshots illustrates the case of a Tv Image - peaking at about 50% of a Core.

 

I've retested with TV 25s and 30s Exposures to Confirm.  I've also tested in Frame&Focus vs Imaging for additional Confirmation.

[admin]

That is normal then, the background worker process does some pretty heavy lifting... it loads the image, of builds the histogram, it reads the exif data, it writes the exif data, etc. serialize the result to send to the UI process, etc...

 

The 100% CPU is normal and can take up to 30 seconds on some computers and then it goes down to 0 until it gets another image.

 

The background worker process runs on a separate core than the UI process.

 

How long does the 100% usage run for after a single image download?  More than 30 seconds?

[s3igell]

Background Worker thread only impacts the CPU when there is ongoing Background Image File Processing to be performed, correct.  And the longest I've seen it last on my Laptop (even the lowly old AMD DualCore with 2GB) has been about 15-20 seconds.

[admin]

Background Worker thread only impacts the CPU when there is ongoing Background Image File Processing to be performed, correct.  And the longest I've seen it last on my Laptop (even the lowly old AMD DualCore with 2GB) has been about 15-20 seconds.

 

Yes, only when there is something in the queue being worked on.  15-20 seconds is normal.  No worries then.

 

Regards,

[s3igell]

No worries then.

 

But still concerned by the unnecessary 100% Core usage by the UI during Bulb Exposures.

 

Right ??

[admin]

No worries then.

 

But still concerned by the unnecessary 100% Core usage by the UI during Bulb Exposures.

 

Right ??

 

Yes, i'll run more tests.