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 > <anto...@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 > <ghesk...@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@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@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@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 > _______________________________________________ xorg@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
