An HD video (or in general, screen broadcasting), at 1920x1080x32bpp
@60fps, needs 3981312000, i.e. 4 Gbps.
That means that 10 thin clients need 40 Gbps to perform with no data
loss, which no server can send.
So the only way for thin clients to work is to find workarounds to send
less data.
VNC, X2go, RDP etc capture the screen periodically and so drop frames
and end up sending less data, at the quality loss that you've seen.
Remote X11 and gvirt don't have the "capture the screen" logic, and they
send all the screen drawing data, and since that data can't fit in the
LAN, they end up slowing down the applications.
So, with VNC/X2go/RDP etc, VLC player will render 60 frames in a virtual
screen on the server, and then VNC will only capture e.g. 10 of those
frames and send them to the client.
With X11/XVideo/gvirt, VLC will only render e.g. 10 frames directly on
the client.
So no, there's no way to render 60 fps to the client since they can't
fit on LAN, no matter what software or driver or OS you use.
...unless:
You use some special software that receives the source of the video,
while it's still compressed, and transmits that one to the client.
For example, HD youtube videos only need 1-2 Mbps, because they're
compressed as mp4 files (and there's some quality loss involved at the
initial compression stage).
So if there's native support in the OS and in the application software
and everywhere, to detect such video sources and redirect them to the
client, to be decompressed there,
and if the client is good enough to do the decompression,
then, for *some* content, it can work fine.
That's what Windows' RemoteFX is all about. But remember it can only
work for some content and only for some software, it's not able to
handle all the various cases where some application needs to draw on
screen. So e.g. doing an Impress presentation with a fade effect won't
benefit from that, because it doesn't involve a compressed video source.
And selecting 100 cells in Calc which causes a lot of screen updates
won't benefit from that either.
That's why the way to go are LTSP fat clients. LTSP fat clients are
still diskless and netbooted from the same image on the LTSP server, but
they use their own CPU and RAM to run the applications, and thus they
work fine with even 100 Mbps LAN bandwidth.
You can find cheap fat clients with less than 100€ each, so it doesn't
make much sense to invest on thin clients anymore, e.g.:
https://www.aliexpress.com/store/product/New-arrival-Beelink-Pocket-Z83-Windows-10-Mini-PC-Z8300-64bit-1-84GHz-2GB-RAM-32GB/1871240_32640039781.html
http://www.gearbest.com/tv-box-mini-pc/pp_343636.html
There's even a thought that LTSP 6 might completely drop support for
thin clients.
Cheers,
Alkis
On 01/03/2017 06:35 πμ, Michael Pope wrote:
> I've just been reading up about the new Virtual GPU support for VMs in
> Kernel 4.10 and was wondering if this could be used for LTSP clients to
> keep applications centralised still but get the GPU of the clients to do
> the rendering.
>
> The problem I have at the moment is some applications have to be
> installed within the client image such as VLC, my browser, skype this is
> due to heavy use of video in these applications.
>
> Could I put my LTSP into a VM and within my thin client image use Kernel
> 4.10 on an intel GPU compatible thin client and use the thin client
> image to connect to a virtual machine on the server which would use the
> graphics card of the thin client?
>
> Or
>
> Is there another way in which LTSP could use the gVirt directly to
> provide applications which are installed only on the server the ability
> to talk directly with the thin clients GPU?
>
> from
> Michael
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
