Question about X on the arm's.

[Carsten Haitzler (The Rasterman)]

On Mon, 28 Nov 2016 08:49:03 -0500 Gene Heskett <gheskett at shentel.net> said:

> On Monday 28 November 2016 07:31:07 Thomas Lübking wrote:
> 
> > On Sun, Nov 27, 2016 at 07:29:14PM -0500, Gene Heskett wrote:
> > >Okay anyone, 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.
> >
> > pass it "-listen tcp", it should open a connection on port 6000+n
> > (where n is the server, starting with 0) and you can "export
> > DISPLAY=remotedomain:0.0" to run X11 clients on that server.
> >
> > Notice that this is no good idea unless on a local, friendly network.
> 
> It is, I am the only user, and its all behind dd-wrt, which has not been 
> penetrated in over a decade. If it wasn't for the need of a switch that 
> allows these machines access to the net for updates and such, this 
> particular cable could be 10" long. But since there is a gigabit switch 
> on the other side of the room, the cat6's will be 50' each by the time 
> they are fastened down with romex staples.
> 
> The source SBC, an R-Pi 3b which is running an up to date raspian (debian 
> Jessie built for arm) is running LinuxCNC, which is commanding a 1500 lb 
> 11x36 Sheldon lathe about 65 yo, will be feeding the display data to a 
> odroid64, which is claimed to be able to drive a 4k display with a 60 Hz 
> refresh rate.  But when doing so over the ssh xforwarding encrypted 
> path, is so slow the screen refresh is about 3x a second. Very 
> distracting, and potentially dangerous when the machine can move 2 or 3 
> inches in that time frame.  Changing ssh to a faster protocol only got 
> it up to 5 or 6 frames. I need to get that flicker rate up to a less 
> distracting rate, something above 20 Hz if possible.  The raspi looks at 
> the  machine and takes corrective action every millisecond but it hasn't 
> got the memory to do the x at the same time. The odroid64 has 2x the 
> memory and more gpu's and if I can get the data to it, ought to be ble 
> to do it in real time.
> 
> > Also, all caveats with "modern" toolkits apply here the same (they
> > tend to be dead slow over tcp because of the massive image putting,
> > you'll only get indirect GL etcetc.)
> >
> > Cheers,
> > Thomas
> 
> 
> We will see, if I can make it work. I was told I was supposed to just 
> remove the '-nolisten tcp' from its launch of 
> exec /usr/bin/X "$@"
> in xinit/xserverrc, and that would enable it, no one else has said to 
> just remove the "no".
> 
> What would be the nmap line to show that it is indeed listening?
> 
> Thank you Thomas.
> 

ssh adds a lot of overhead as it has to decrypt/encrypt, etc. as well as then
pass on protocol. depending on the client you are using this could mean a LOT
of data having to go through this pipe. clients can easily saturate a 100mbit
network. even a gigabit network. it depends on how they work.

if you have your xserver listening as normal, it'll be listening on port 6000
if it's display 0 (locally DISPLAY=:0 or DISPLAY=:0.0). 6001 for :1, 6002
for :2 etc. as well.

to connect to that display from another machine simply:

  export DISPLAY=machinename:0

or replace machinename with ip address like:

  export DISPLAY=192.168.0.2:0

now run whatever x app. note you will ALSO need authorization. the SIMPLEST way
is to disable authentication. locally wherever x is running as the person who
has authority to connect just do:

  xhost +

you'll have disabled all auth checking for all hosts. read manual page for
xhost for more info. you may also want to read the manual page for xauth.

your connection either way will not be secure. it can be hijacked or listened
to (man int he middle etc.) so as long as you trust your network you're ok, but
in general this is a bad idea.

be aware that while this will drop the overhead of ssh, your network itself
still is a bottleneck. performance can be pretty bad even on gigabit. it all
depends on the workload your clients use. since a lot of clients have moved
rendering client-side either in software where they just shuffle blobs of
pixels to x, or they use opengl with direct rendering and a gpu to do the heavy
lifting... the first will eat up bandwidth like there is no tomorrow, and the
second will mean clients can't run at all as direct rendering requires you be
on the same machine with your client and gpu as the x server, indirect (glx
indirect) does exist... but it has been pretty much deprecated and no one tries
to really use it anymore for performance reasons...


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