Question about X on the arm's.

Tue Nov 29 08:19:58 UTC 2016

On Tue, 29 Nov 2016 01:04:23 -0500 Gene Heskett <gheskett at shentel.net> said:

> On Monday 28 November 2016 22:58:37 Antoine Martin wrote:
> 
> > 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)
> > 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 motion of an single color icon that represents the cutting tool, the 
> swap of pixel color to show the tool has passed, and the image data that 
> represents a 5 or 6 digit(.001mm or .0001") digital position reading in 
> up to 9 dimensions, but normally 2-3-4. 2 obviously for a lathe, 3 for 
> the average milling machine or maybe 2 more to indicate rotational table 
> movement around the main 3 in a milling center.  But thats big stuff 
> generally.  So no, not more than 5% of the screen area is actually being 
> modified on a frame by frame basis.
> 
> > > 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 more
> > > 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.
> 
> That too, but looking at the logs, this odroid64 as 4 cores that speak 
> arm, and 4 gpu's, and linux does not assign them to do anything in the 
> builds available.  Not one darned thing! So maybe android is better off, 
> but I suspect the penguin is not gonna get any help until Mr. 
> GotLotsaGoldenRocks throws money at the coders because his flashbangy 
> new smart phone product needs it.  TANSTAAFL folks.

this has nothing to do with android or linux but to do with the fact you are
doing remote display through a tiny thin straw.

the rpi and odroids really only manage 100mbit or so even if they have gigabit
nic's. doing remote display with x means either transporting across draw calls
(as discussed this kind of rendering has really died) or transporting across
pixels after rendering locally and this means transporting them across
uncompressed in their full form.

display mechanisms like miracast involve completely rendering locally with the
local gpu or cpu or both THEN using a local h264 encoder to encode as a video
stream then sending that video stream across the network. the bandwidth needed
for this is far smaller but it involves having an encoder at your execution
point for the app. it's a completely different display technology. you can use
the cpu to encode but this also needs ridiculous amounts of cpu power.

> 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

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