Question about X on the arm's.

Tue Nov 29 08:36:39 UTC 2016

On 29/11/16 13:04, Gene Heskett wrote:
> 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.
Assuming that this particular application doesn't damage (a sort of X11
repaint notification) the whole window unnecessarily, 5% of 4K at 20 fps is
just ~265Mbps and is easily doable over a 100Mbps connection with barely
any picture compression, even on arm.
ie: try xpra's lz4+rgb picture encoding mode on the 100% speed setting.

Cheers
Antoine


> 
>>> 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.
> 
> Cheers, Gene Heskett
>