×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Issues with high acquisition rates

  • Posts: 9
  • Thank you received: 16
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.
The following user(s) said Thank You: Emmanuel Bertin
6 years 1 month ago #23566

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 2
I suspected that the "Failed to save file to" in "Upload: Client" mode was due to Ekos running out of file descriptors. This seems indeed to be the case. The problem vanishes when I push the maximum number of open file descriptors to 4096 per user (was 1024 by default on my system). Sounds like a close() is missing somewhere :).
Last edit: 6 years 1 month ago by Emmanuel Bertin.
6 years 1 month ago #23585

Please Log in or Create an account to join the conversation.

Well, where is the close() missing? I know this has been reported before, but whenever a new FITS is used, the previous one is always closed first.
6 years 1 month ago #23588

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 16
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 rapid looping 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!
The following user(s) said Thank You: Emmanuel Bertin
Last edit: 6 years 1 month ago by Leonard Bottleman.
6 years 1 month ago #23596

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 2
Thanks for the tip Leonard! Here the output of ls -l /proc/29669/fd, where 29669 is the PID of kstars when running an acquisition sequence from the CCD simulator (the same happens with the ASI camera, connected remotely or not):
...
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1570 -> socket:[876722]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1571 -> socket:[876723]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1572 -> socket:[871147]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1573 -> socket:[871148]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1574 -> socket:[874775]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1575 -> socket:[874776]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1576 -> socket:[875769]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1577 -> socket:[875770]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1578 -> socket:[871149]
lrwx------ 1 bertin bertin 64 Feb 25 00:14 1579 -> socket:[871150]
...

And it goes on and on until I stop the acquisition. Aborting does not close the sockets, I have to quit kstars to free the descriptors. It happens only when the exposure time is about 1s or less, irrespective of the raster size (the simulator takes only a few ms to generate the 128x128 rasters in this test). This is with fast looping off (I have to turn it off otherwise it creates all kinds of issues), and without FITS viewer. The other processes (indiserver and indi_simulator_ccd) do not accumulate descriptors.
- Emmanuel.
Last edit: 6 years 1 month ago by Emmanuel Bertin.
6 years 1 month ago #23622

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 16
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
The following user(s) said Thank You: Jasem Mutlaq, Emmanuel Bertin
6 years 1 month ago #23634

Please Log in or Create an account to join the conversation.

I don't have control over other Qt/KDE software, but if they have a bug, we can help them resolve it. You can turn off the sounds from Settings --> Configure Notifications. Maybe I should turn them off for < 1 second captures?
The following user(s) said Thank You: Emmanuel Bertin
6 years 1 month ago #23635

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 2
Thank you Gentlemen, turning off the sound notification does indeed solve the problem! Sorry for not thinking about this.
Just in passing, here is another non-critical issue which happens frequently with high acquisition rates. As you can see below the image file numbering scheme is quite erratic at times:
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-11_1938.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-12_1939.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-13_1939.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-14_1940.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-15_1940.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-16_1941.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-17_1941.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-18_1942.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-19_1943.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-20_1944.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-21_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-22_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-23_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-24_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-25_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-26_1945.fits
-rw-rw-r-- 1 bertin bertin 4248000 Feb 21 23:49 NGC2683_Light_0.500_secs_2018-02-21T23-49-27_1945.fits
Nothing serious but worth mentioning.
btw, is this forum the best place where to report and file specific bugs? I have started to dig into the code, I will try my best to help.
Thanks!
6 years 1 month ago #23639

Please Log in or Create an account to join the conversation.

I made quite a few changes yesterday to both INDI & KStars about this issue, but need to test it more today. For KStars bugs, the best place is bugs.kde.org
For INDI bugs, here: github.com/indilib/indi/issues
The following user(s) said Thank You: Emmanuel Bertin
Last edit: 6 years 1 month ago by Jasem Mutlaq.
6 years 1 month ago #23650

Please Log in or Create an account to join the conversation.

Time to create page: 0.303 seconds