Note also: I have no real explanation for why Case 4 was faster than Case 5, particularly if that wasn't the case for Case 1 and 2. However, one important clue is the fact that VGL_USEXSHM=0 was required for Case 5. If in fact you were using the VGL Transport with JPEG encoding, then VGL_USEXSHM could not have had any effect unless you set it on the client machine (VGL_USEXSHM only affects the X11 Transport or vglclient.) I'm not 100% convinced that you were using the VGL Transport in Case 5. But regardless, like I said below, running a window manager with Cases 1, 2, 4, or 5 is not a good idea.
On 3/18/19 10:54 PM, DRC wrote: > Ah, OK. It makes much more sense now. Some notes: > > Case 1, 4: > > This is using the X11 Transport over SSH, which is never a good idea. > Even with gigabit, the most you could ever hope to stream with > uncompressed XPutImage() requests is in the neighborhood of 30 > Megapixels/second (bearing in mind that each pixel is a full 32 bits in > this case.) Also, the overhead of SSH is likely going to reduce the > throughput somewhat because of the immense size of the data stream (and > thus the CPU cycles required to encrypt it.) Perceptually lossless JPEG > (Q95, 4:4:4) over 100 Megabit can easily do > 50 Megapixels/second, by > comparison. In short, this configuration is not something that should > ever be used in production. > > Case 2, 5: > > Assuming you're already running vglclient on the client machine, this is > the equivalent of using vglconnect (Note that '-c jpeg' is superfluous, > because VGL will automatically select the VGL Transport w/ JPEG if it > detects this configuration.) This configuration should work fine if > you're running a regular application over the gigabit CAN, but running a > window manager is a different story. Window managers do a lot of very > image-intensive operations and require a lot of back & forth with the X > server, so in general, it's not a good idea to run them without an X > proxy. It could simply be that i3 is less well-tuned for a remote X > connection-- window managers in general aren't designed to be run over > remote X. Even on a gigabit CAN, there is going to be some network > latency and overhead, and that can add up if the application (the WM, in > this case) is issuing a lot of fine-grained X requests. > > Cases 1, 2: > > Not sure what you mean by "Cases 1 and 2 with i3 requires XFree86 to be > disabled." XFree86 hasn't been used by any Linux distribution in quite > some time. > > Case 3, 6: > > This is an X proxy, so the actual connection to the X server is entirely > within the server machine. Thus, window managers are appropriate in > this configuration. > > Cases 1, 2, 3: > > VGL_FORCEALPHA was required because of the amdgpu drivers, as previously > noted. > > Cases 4, 5: > > Still very odd that VGL_USEXSHM=0 was required here, but the fact that > Cases 1 and 2 didn't require that points to an issue with the server > machine. > > > On 3/18/19 2:47 PM, Jason wrote: >> >> Good Afternoon, >> >> >> My mistake, i3 is a window manager (I get them mixed up from time to >> time :) ); LightDM is the display manager. Here is (to my knowledge) >> the layout of the environments: >> >> >> VGL_Env.png >> >> >> * >> >> Cases 1, 2, 4, and 5 do not work well when used with an i3 desktop >> (but well for MATE, KDE, etc.). >> >> * >> >> Cases 1 and 2 with i3 requires XFree86 to be disabled >> >> * >> >> Cases 4 and 5 with i3 requires the VGL_USEXSHM=0 to be used >> >> * >> >> Cases 1, 2, and 3 requires the VGL_FORCEALPHA=1 to be used >> >> * >> >> Case 4 seemed to work better than Case 5 in performance >> (increasing the compression core count helped, but was still slower) >> >> * >> >> Case 6 works when running vglrun in a terminal, but not when >> launching the desktop environment with "vglrun +wm" (audio is lost) >> >> (Understandably, cases 3 and 6 are not supported like TurboVNC is, but >> I included them for completeness sake) >> >> >> In no case is the scope going wider than CAN (while there is potential >> for WAN, we are focusing currently on the LAN-CAN performance). >> >> In all, I am slowly, but surely understanding how Xorg, GLX and SSH >> all tie together. That being said, I appreciate your time helping us >> out with all of this. >> >> >> Thanks, >> >> Jason >> >> -- >> You received this message because you are subscribed to the Google >> Groups "VirtualGL User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/virtualgl-users/3174c035-7240-4a74-9b15-860f770f39f0%40googlegroups.com >> <https://groups.google.com/d/msgid/virtualgl-users/3174c035-7240-4a74-9b15-860f770f39f0%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/5ce4238d-a511-2780-1f1a-109e4d40c974%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
