私は西海岸のサーバーにSSHingしています。X11フォワーディングのSSH圧縮
私はX11フォワーディングが機能するように管理していますので、GUIアプリケーションを便利なところで起動できます。しかし、すべてのX11転送アプリケーション（特にemacs！）では、入力（キーストローク、マウスクリックなど）とレスポンスの間に非常に遅れがあり、時には迷惑になることから、 Aをすることができますが、Bは遅れが非常に大きいので起こります。
SSH圧縮は潜在的な原因ですか？どのような種類の圧縮を使用する必要がありますか？
X11グラフィックスは、多くの帯域幅を占有します。遠隔地のホストが離れている場合（つまり、LAN上にない場合）、エクスポートされたX11アプリケーションでは、おそらく低速になります。
SSH圧縮についてはわかりません。パフォーマンスは、CPUパフォーマンスなどの他の要因に依存する場合があります。 ssh manページから：ここで
-C Requests compression of all data (including stdin, stdout,
stderr, and data for forwarded X11 and TCP connections). The
compression algorithm is the same used by gzip(1), and the
“level” can be controlled by the CompressionLevel option for pro‐
tocol version 1. Compression is desirable on modem lines and
other slow connections, but will only slow down things on fast
networks. The default value can be set on a host-by-host basis
in the configuration files; see the Compression option.
あなたは物事を高速化するために使用できるいくつかの他の回避策されています。代わりにX11フォワーディングを使用したGUIとの相互作用の、より良い持っている何かを
あなたは、具体的emacsを述べたように：
-nw, --no-window-system Tell Emacs not to create a graphical frame. If you use this switch when invoking Emacs from an xterm(1) window, display is done in that window.
コマンドラインオプションは、SSH経由で作業する場合、それが唯一の文字を転送しなければならないので、これは再描画ではない、（はるかに高速にすることができていますX11上の画面全体）。
私の問題は構成に関するものではないと思います。これは私が選んだツールに関するものです。私はVNCを以前に動作させるのにいくつかの問題を抱えていましたが、別のショットに値するかもしれません。ありがとう！ – Zearin
実際によく書かれたX11プログラムは、多くの帯域幅を消費しません。 X11の主な問題は、ほとんどすべての操作に対して完全な同期往復を実行し、多くの操作を非同期的に実行できるXlibの悪い書き方です。 Xcbのような別のX11プロトコルバックエンドを使って、クライアント上のGUI全体をラスタライズしてネットワーク上で厄介なことを実行しないと、低帯域幅、高レイテンシー接続上のプレーンX11 over TCPは実際には非常に有効です。しかし、多くのプログラムはひどく書かれています。私はNXまたはsshが添付されたXpraを推奨します – datenwolf
+1 @datenwolfこれは、帯域幅よりもレイテンシとナンバーオーバーラウンドトリップに関するもので、Xlibはx11プロトコルの全二重非同期性を利用して非常に悪い仕事をしています（プロトコル自体は待ち時間に対して非常に最適化されています） –