Question about X on the arm's.

Tue Nov 29 08:24:35 UTC 2016

On Tue, 29 Nov 2016 10:58:37 +0700 Antoine Martin <antoine at nagafix.co.uk> said:

> On 29/11/16 10:28, Carsten Haitzler (The Rasterman) wrote:
> > 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.
> Even 100mbit is perfectly usable for remote access provided you use the
> right tools and make some sacrifices. FYI: 4K at 60 "fits" in H264 ~60Mbps.
> But again, as I said above, just don't expect to handle fullscreen video
> on arm where *we* don't support hardware H264 decoding. (though other
> tools might)

but we're not talking video streams. we're talking x11. and with x11 to push
pixels across a network basically means xputimage and that means the bandwidth
requirements i have given (or sending the draw calls and as discussed this is
pretty much dead for various reasons).

> And obviously, if you want lossless you probably aren't doing 20fps.
> At this point it is probably best to ask the OP exactly *what* he needs
> forwarded at 20fps.
> 
> > the days where your clients upload some monochrome 1 bit bitmaps and then
> > just render with xfillarc/xcopyarea etc. etc. are kind of over.
> Definitely 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... :)
> Yes, that's exactly the use cases that we handle.
> 
> Cheers
> Antoine
> 
> http://xpra.org/

xpra is its own display system effectively separate from x11. at least in terms
of display as x11 protocol supports no forms of compression (let along lossy
compression) of pixel data. xpra is a separate display tech much like rdp,
miracast, vnc etc. would be. :)

> > 
> >> 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