the first thing I see is that in Remote the acquisition time is very lengthened because of transfers to the client. In my case the transfer may take 5-10 sec depending on the camera used (2-3 sec with the DSI and 8 sec average with the asi in full format). When you make 20 acquisitions it's good but for 200-300 it's already less good.

So I would imagine an acquisition in a Tmp folder on the server and a parallel process that takes care of transferring the files as long as there are. So that the acquisition continues even if the file is not yet 100% transfer.

Why don't you save on the remote machine (i.e. LOCAL mode) and then transfer everything back to the client when it's complete?

it's true and that's what I intend to do but I love this feature of live viewing and this transfer that does as you go. The funcion exists and it could be optimized. Now it's probably easier said than done .

In any case I really want to thank all the people who founded INDI / kstars / ekos because it is really a big job and it is admirable .

rsync could provide this functionality as a background thread for the transfer. It has flags that will do things like resume an interrupted transfer, not transfer things that have already been sent, delete after sync, etc. You can do this today if you desire, out of band. It would be neat to integrate it though and have the viewer bring the next image up after it is transferred. Depending on the implementation of rsync, it also has bandwidth limiting functions, which could be used to ensure that you can still have control over the remote machine. Image transfer would otherwise easily saturate your control channel.

I have not been able to get to this point yet. The use of rsync is something I have considered for the Ekos images for a few reasons: backup images once done, and for live stacking via Astrotoaster.

If I can get a few things fixed, this is one of the things I hope to get too.


Sent from my iPhone using Tapatalk Pro

what kind of network are you running on between the machines ?

I have the dome 400feet from the house, with a gigabit connection. Transfer times are only slightly longer than they are on the local machine. But, if I switch from using the fiber network, to the wifi, whole different story, transferring a 32 meg fits file takes a substantial amount of time over that.

If you are concerned about transfer latency, then a slow network is not a viable option.

Rsync is essentially adding an asynchronous facet to the capture transfer isn't it? It does not change its efficiency. So whatever the network bandwidth, the issue would reappear as payload scales (but it saves to make FITS blobs compressed in the INDI driver panel of course!). The problem is indeed the way captures are recovered: Ekos, for instance, will wait for captures to pop up before assessing a capture step is complete. I suggested an INDI driver manage a storage backend in another thread, but I'm not sure it would solve all the issues...

-Eric

Envoyé de mon ASUS_Z00AD en utilisant Tapatalk

Yes it adds async transfer, but the important part is it would do it out of band. That is, you would still be writing to the local storage, so as fast as that can write, it can start capturing again, just as it does today. The transfer could actually be many images behind, and it should not matter that way. This is the method that would work best for my setup where I have ample local storage. If others have the need to not store local at all, then it does not help much. The bandwidth is the bandwidth and the only help is a faster transport.

Not sure if this is any use, but you could use a Dropbox dir and save the data on-site there. Then have this would sync to your other devices that have dropbox installed and not block any other operations.

My typical imaging night has 400-600 32MB files. It would take me days to get that to dropbox with my internet uplink speed

Ouch, thats a lot of data alright

Thank you for all the answers.

Actually at am wifi and so it's slow . It is true that I will use it in local recording and transfer the files at the end of session simply.