Question about X on the arm's.

Tue Nov 29 03:28:35 UTC 2016

On Tue, 29 Nov 2016 09:43:54 +0700 Antoine Martin <antoine at nagafix.co.uk> said:

> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett <gheskett at shentel.net> said:
> > 
> >> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote:
> >>
> >>> On 11/27/16 04:29 PM, Gene Heskett wrote:
> >>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X
> >>>> is its own forwarding agent, why am I even using ssh? saying I'm not
> >>>> needing ssh at all.
> >>>
> >>> X can connect directly, but without the encryption & compression that
> >>> ssh adds when it acts as the forwarding agent.  ssh has been the
> >>> modern recommended solution for years - all major distros have started
> >>> X with "-nolisten tcp" for over a decade, and recent versions of Xorg
> >>> made that the default, such that you need to go specify "-listen tcp"
> >>> to enable the old direct TCP connection method now if you want to
> >>> avoid ssh.
> >>>
> >>>> So, where can I find the definitive tut on doing this because our
> >>>> attempts are failing?  What I was able to find on the xorg web pages
> >>>> last night was up to 3 major versions out of date.  I need a tut
> >>>> that deals with X11R7 and up.  Is there such a thing?  My google-fu
> >>>> is failing me.
> >>>
> >>> Our recommendation for X11R7 remote connections is "Use SSH X11
> >>> Forwarding."
> >>>
> >> Which works but at very lethargic speeds. 3, 4 frames a second.  I need 
> >> 20 or more. This odroid64, with at least 3 gpu's is said to be able to 
> >> do a 4k display at 60 frames a second.
> > 
> > that'd be simply display REFRESH. not actual rendering of content. and
> > forget REMOTE display over ssh over a bottleneck of a network device.
> > forget trying to get anything like high performance over a network
> > connection when it comes to display. don't even bother. it's a waste of
> > time.
> I beg to differ. An arm CPU certainly makes this more of a challenge,
> but it is not a lost cause... just don't use SSH forwarding, some tuning
> IS required.

it has nothing to do with an arm cpu... it's the network. see below. if someone
is quoting "this arm SoC can do UHD at 60hz" then you're in fantasy land
thinking you can even get anywhere NEAR that. even 1080p at 20hz would need 1.3
gigabit of pure bandwidth on the network without any protocol etc. overhead. so
let's round that up to 1.5 gigabit allowing for overhead and other misc
traffic. you'd have to keep that bandwidth fed solidly ANd also copy data to
the framebuffer etc.

> > if it displays at ALL - be
> > happy. to provide updated pixels at 60hz for a 4k display would require a
> > 16 GIGABIT network... with NO OTHER TRAFFIC on it at all. and no network
> > packet/protocol overhead. so let's make that 20 gigabit. that's assuming
> > xputimage with 24bpp images (padded out to 32bpp as that's how xputimage
> > works). that does not account for bottlenecks outside the network itself
> > (the system at either end and it's tpc/ip stack, kernel, memcpy's etc.
> > etc.).
> I don't think the OP is trying to watch a 4K video over TCP, rather
> stating that his hardware is capable of pushing 4k at 60 pixels, which is
> why he was expecting better results.

see above. 1080p @ 20hz would exceed any network adaptor he has. i don't know
what this odroid64 is, but if he;s talking of the odroid's from hardkernel,
then the TOP of the line they have is the xu4 (or xu3 - not available anymore
but identical to the xu4 simply with more usb ports, more display ports etc.).
the xu3 has a gigabit port. let's get to some reality...

i have an xu3. i also have a pc. both with gigabit ethernet ports attached to a
gigabit switcch. guess what? the BEST you can get without any overhead (simple
ftp) is about 11-12Mb/sec ... ftp reports:

746748440 bytes sent in 63.9 seconds (11.1 Mbytes/s)

when transferring this EATS kernel space cpu. ftpd is consuming 74% cpu and its
almost all kernel space (system) cpu. that's JUST to transfer a file directly
to disk. it'll be doing it all to ram cache so it isn't i/o limited by emmc as
the xu3 has 2Gb of ram.

so without any encryption overhead the network can at best do let's say
12Mb/sec. at just 1080p 24bpp (padded to 32bpp) that's 1.5 fps. 1.5. that's all
his device will do. that is of course assuming generating new pixel data every
frame (client side rendering). sure. 3fps if it's 16bpp. if the app uses
xrender and pixmaps and uploads all data first this can improve, but clients
are more and more moving away from that model.

> If you exclude the 4k fullscreen video use case - which is a worst case
> scenario for remote display (there are tricks to deal with that too if
> you are willing to make sacrifices), then screen updates are actually
> much more manageable, even on a 1Gbps shared link.

nope. not really. do the math. buy a few arm dev boards. :) find out that you
won't get 1gigabit. even 100mbit is pushing things.

the days where your clients upload some monochrome 1 bit bitmaps and then just
render with xfillarc/xcopyarea etc. etc. are kind of over. today data is 32bpp
with lots of new client-side generated data all the time and mopre and more
clients try and use opengl to get acceleration and speed and that's really a
local-only thing these days. yes i know of glx indirect rendering. get that to
work over a network to an arm board which is egl/gles... :)

> Cheers
> Antoine
> 
> 
> > 
> >>> Unfortunately, so few people are willing to help write X11 docs that
> >>> there isn't a whole lot of stuff written since the X Consortium
> >>> stopped paying doc writers in the mid 90's.
> >>
> >> Yikes! NDW I cannot find uptodate docs & tuts.
> >>
> >> Thanks Alan, I appreciate the candor.
> >>
> >> Cheers, Gene Heskett
> >> -- 
> >> "There are four boxes to be used in defense of liberty:
> >>  soap, ballot, jury, and ammo. Please use in that order."
> >> -Ed Howdershelt (Author)
> >> Genes Web page <http://geneslinuxbox.net:6309/gene>
> >> _______________________________________________
> >> xorg at lists.x.org: X.Org support
> >> Archives: http://lists.freedesktop.org/archives/xorg
> >> Info: https://lists.x.org/mailman/listinfo/xorg
> >> Your subscription address: %(user_address)s
> > 
> 
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com