One of the main reasons I have moved to kstars/ekos is the client/server architecture and the lower network bandwidth requirements. I had tried VNC, TV and Windows Remote Desktop with other capture software, only to struggle with very slow and/or dropped connections most of which were range related. With ekos, I have not had a single network issue...it is rock solid and totally reliable. It's pretty obvious to me why this is the case: indi protocol is just passing data between client and server whereas VNC is passing pixels to render the UI - - every move of the mouse, every open/close window results in passing pixels to repaint the screen.

My question is, has anyone done a real comparison of the two from a bandwidth perspective? I tried a (VERY unscientific) test using Bandwidth+ on my Mac connecting to my indi server on RPi. I ran two 3 minute tests: one using kstars on my Mac to perform some test captures, auto-focusing, plate-solving, and the second test using VNC to perform similar tests. After the 3 minutes, the first test resulted in just under 5mb data transfer and the second test resulted in over 30mb data transfer. Pretty significant.

My installation is remote. I've not done a bandwidth comparison as the response of VNC is the real problem I contended with. Remote Desktop was much better but only on Windows. I believe the Remote Desktop implementation on linux (incl RPi) simply wraps VNC locally on the server, so the VNC lagginess really isn't solved for. I settled on x2go over SSH and have been happy with that for a few years now. I run the client on my macbook and control my linux server running KStars & indi with it over a VPN.

Kstars/indi implementations will handle things better as the KStars user interface will remain responsive while the indi protocol is handling back-end comms. The caveat is that there could be software timeouts if latency and bandwidth are not good enough. I'm not able to speak to that as I've not run into it but I've seen it numerous times with other client/server apps. My favorite example is opening an MS Excel file on a Windows share that is even minimally distant (other side of the city). The protocol and software just don't (or didn't) handle it well.

One thing to consider is the size of the data being transported between the indiserver & Kstars. It's really not a problem if you're on a local network and have a reliable, speedy network. However, for a remote operation it's going to be a primary factor in the performance of things. Sending guiding images over a VPN over the Internet is not likely to be conducive to good guiding practice, even if it is "fast" from a bandwidth perspective. This is not to say that it won't work - it just might not work as well as you'd like it to.

I haven't done a comparison but there is no doubt the bandwith required for VNC is far greater while actually being used.

The problem is that you need to keep your main computer runnning using the INDI protocol whereas I can VNC into my Raspberry Pi and because it is running independently I can close the VNC connection and everything keeps running.

Paul

@schwim - I am what I call "near remote" from the backyard, whereas it sounds like you are truly remote. That means I can have ekos store all my images on the Pi sd card, then I pull them off after my session. Eliminates having to push all the subs over the network and the inherent lag on the imaging session until the transfer is complete. I still use VNC if I need to get to the OS or apps other than indi server on the Pi, but that's usually before or after a session.

@paul - great point on keeping kstars/ekos running on the client machine. I've never had a crash (knock on wood), so it's been solid so far.

The reason I was looking for some hard data, rather than my anecdotal findings, is because I'm working on convincing a few of my imager friends to switch to kstars/ekos!

Keeping Kstars/Ekos running on a separate machine could be seen as a benefit. For example - I can't run TSX (needed to operate my mount) at the same time as Ekos on my RPi, but I can run indiserver on the RPi with TSX and keep KStars on another computer. This works quite well as long as you anticipate things like network interfaces going to sleep, lossy networks, latency and such.

Check out x2go when you get a chance. It was a game changer for me. VNC simply just doesn't come close in performance.

I will check it out. Thanks for the tip.

Thanks for the tip, VNC performance has never been an issue for me but I am always looking at ways to improve things so I will investigate x2go.
Paul

Hi,

Having started with PCAnywhere for remote control (on dial up lines where 56kb was heaven) and used numerous client server flavours it is not a simple comparison of data transfer.

Today most people dont even know how to throttle Remote Access software(e.g. 24bit not 32bit res ,encryption off etc) this reduces the data capacity requirements . But would it be worth it if you want to see the other end as if you were there.

The Client Server approach is great so long as the server and client have the power (you are only as good as your weakest link) to process the applications(Camera(s),Mount etc) and the extra network traffic(Indiserver etc) AND it can handle varying response times and/or failures.

Today's hardware has removed most of the speed/capacity problems especially if you don't use wireless (especially in "crowded" areas) and it is easily and cleanly ,on the most part,replaced with "upgrades" to over come speed/capacity issues.

You can not say that of Client/Server - e.g. a new driver behaves badly and slows the client/server process - ok that would effect either approach but you would notice this more in Client/Server situation - you may not even notice this with RDP/VNC approach .

I rabbit on - what I am trying to say is dont just measure data as its a lot more complicated than that and no one solution is perfect .

There are a lot more pro's and cons than just "data transfer" - e.g. For me its Less wires and flexibility. I bet you would all have your own ideas.

In the end - "Does it work for you?" if so its the right method !