Tunnelling raw framebuffer using a light/fast fbvnc through a ssh tunnel where compression is turned on does seem to work better for me than using tigervnc. Wondering (suspecting) that may be due to not attempting to compress already compressed data content? i.e. if the output from the vnc server is already compressed and that's being conveyed over a ssh link (tunnel) that is using compression, then there's a additional overhead of attempting to (or actually applying) compression of already compressed data/content (that could even lead to slight data enlargement and involves CPU cycles).
Our internet feeds down at 100Mbs, uploads at 10Mbs. Our wifi also runs at 10Mbs. So the desktop (Fatdog desktop server via vnc) that is hard wired, can download files at 100Mbs, and with my laptop (wifi) being fed the screen contents. I also typically set up sshfs mounting of the desktop, so the servers folders appear to be just the same as local folders on the laptop. That's like having the laptop that's wifi net connected being able to download files at 100Mbs, upload at 10Mbs (but where accessing the files is also 10Mbps i.e. through sshfs).
Other benefits of using a thin client (Bulldog style) laptop that vnc's to a Fatdog desktop server through a ssh tunnel is that whilst out and about that detects/flags man in middle attacks (ssh will flag that the servers key had changed). There's also no eavesdropping (as its all tunnelled). As part of setup/bootup I run a script that randomises the MAC, so a fixed mac can't be tracked from location to location. I've also turned KASLR on, so the kernel isn't fixed in location in ram, but is randomly distributed. Yet another benefit is having tmux like functionality of being able to disconnect/shutdown the laptop, and later reconnect very quickly, possibly even from another device, and have the gui desktop exactly the same as how it was left (or to where it had moved on to, such as a kernel compile having completed or large download finished). Whilst the (ssh exposed) Fatdog server can be relatively secure, such as booting using multi-session saves from/to DVD. Very much like secure cloud computing - but where you control the 'cloud server(s)' and routing.
Increasingly 'the cloud' is becoming more restricted, perhaps unlimited downloads/content access to the home (hard wired) server, but limited downloads and access from mobile devices (wifi hotspots often restrict bandwidth/data volumes and/or content accessibility). Recently for instance GoogleDrive is immediately blocking sharing of certain files that I upload to share, such as initrd's. When you entrust to the cloud (microsoft/google/etc.) then not only are you paying for that in the way of 'yourself', but increasingly in the way of 'your data' ... becoming "owned" by others. Fatdog has the capacity to provide "Liberty" and security
I do like a thin client such as if specifically compiling the kernel with localyesconfig - so no other modules other than the ones required are built into the kernel. Smaller code = less attack vectors = more secure. Modules are many and each/any of which, in being just normal 'code', could be loaded and run for ulterior purposes, or where a flaw in one could have that being loaded and the flaw exploited. Again, Fatdog as a "tool-chain" ... is outstanding
