Question about X on the arm's.

Antoine Martin antoine at nagafix.co.uk
Tue Nov 29 03:58:37 UTC 2016


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

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



More information about the xorg mailing list