Leonard Bottleman replied to the topic 'Issues with high acquisition rates' in the forum. 8 months ago

Thanks Emmanuel.

At first I could not recreate the socket leak even when following your instructions.

I then used strace on kstars and discovered that it (actually the QT layer) was constantly looking for phonon4qt5_backend from the qt /usr/lib install. Looking up phonon4qt5 in the system software manager I found several KDE provides packages including a back end gstreamer package. I do not use KDE (just not a fan) and so my system does not have this package installed.

I installed the package.

Afterward at the end of each image capture I got an annoying sound. Worse, when I took multiple images in the scheduler kstars leaked a socket pair per image (in addition playing the sound). It did not leak sockets with preview.

I then removed the package (phonon4qt5-backend-gstreamer) and the socket leak vanished.

If you use KDE you can test if disabling sound notifications stops the socket leak ( option to disable failure sounds ), or if you do not use KDE try removing the package I listed above and restart kstars.

Obviously a real fix is needed, but I am not familiar enough with the kstars source code to be helpful here (I am more of a low level software guy).

Leonard

Read More...

Leonard Bottleman replied to the topic 'Issues with high acquisition rates' in the forum. 8 months ago

I experimented with many short exposures while monitoring the files held open by kstars, indiserver, and indi_asi_ccd.

I saw no open file changes for indiserver or indi_asi_ccd.

For kstars after the first exposure there were 6 additional files held open: a socket, a pair of event fds, /dev/urandom, and the image file (open twice).

When I took many images the number of open files remained the same, with only the open image file changing.

However, if the number of fits viewers increases, then the number of files help open also increases -- I can only reproduce this when I trigger the bug where the image download takes longer than the image exposure, which we know is an issue.

When you think kstars or indi is holding open too many files please get the pids for kstars, indiserver and indi_asi_ccd, and then for each please list the open files:

ls -l /proc/<pid>/fd

Where <pid> is the process pid -- you may want to redirect the output of each ls command to a file.

Then post here the results of what you've found.

Thanks!

Read More...

Leonard Bottleman replied to the topic 'Issues with high acquisition rates' in the forum. 8 months ago

An ASI software engineer replied to my post on the ZWO forum indicating that the long delay for for the exposure completion status to switch from working to success was expected.

This is a bit disappointing, but without access to the code I cannot guess what it is doing that is taking so long.

Read More...

Ajay thanked Leonard Bottleman in topic Losmandy gemini 2 control 8 months ago
Ajay thanked Leonard Bottleman in topic Losmandy gemini 2 control 8 months ago
Leonard Bottleman replied to the topic 'Losmandy gemini 2 control' in the forum. 8 months ago

You can control the gemni2 via usb, ethernet (use the UDP port) or the ST4 port on your camera.

I have used all three methods, and find the ST4 port has worked the best for me.

Read More...

Leonard Bottleman replied to the topic 'Issues with high acquisition rates' in the forum. 8 months ago

I have started a thread on the ZWO ASI forum to address this issue: ASIGetExpStatus 250+ ms delay on Linux asking for assistance in diagnosing the delays.

Read More...

Leonard Bottleman replied to the topic 'Issues with high acquisition rates' in the forum. 8 months ago

While I do not do many exposures under 1 second, I am interested in the ASI indi driver, and so I added some timers to the driver and ran several tests using an ASI 174mini (USB2) and an ASI294mc (USB3).

What I found surprised me.

With an exposure of 0.000032 seconds the driver spent on average over 300,000 usecs (0.3 second) polling ASIGetExpStatus. It only only spent around 18,000 usecs (18 msecs) downloading the image via USB2 at 40% bandwidth.

I tried again with an exposure of 0.5 and got the same results overhead.

When the remaining exposure time drops to (or starts) below 1.1 seconds the indi ASI driver calls ASIGetExpStatus every 10,000 usecs (10 msecs), and for the shortest exposures this function is called over 30 times each, and for a half second exposures it is called over 85 times each.

I then repeated the tests with an ASI294MC in 8 bit mode and the image size reduced to the same as that of the 174 and saw the same overhead.

This implies to me that there is a consistent delay or overhead in either the ASI provided SDK or the ASI camera firmware.

I recommend starting a thread on the ASI forum -- in fact I will do so tomorrow (after searching if any related threads).

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!