Question about X on the arm's.
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
>>>> 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
>> 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.
>> 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
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.
> 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.
>>>>> 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