web-dev-qa-db-ja.com

Linuxでの遅いグラフィカルリモート接続

Ubuntu Desktop 16.04をコンピューターにインストールしました。マザーボードをモニターに接続してボードの電源を入れると、すべてが正常に機能します。VNCを使用してグラフィカルに接続できるようにボードのvino(デスクトップ共有)を構成し、ネットワークでローカルに接続できるようにしました。 VNCプロトコル(Remminaアプリケーションまたはvnc-viewer)。

しかし、モニターから切断してボードをオンにすると、オペレーティングシステムがロードされず、ローカルネットワークから接続できません。 pingコマンドを使用しても、ローカルネットワークで見つけることができません。

マザーボードを購入した会社に連絡し、解決策について尋ねました。彼らは/ etc/default/grubのgrub設定ファイルを変更することを提案しています。

これらの2行のコメントを外すように言われました。

# Uncomment to disable graphical terminal (grub-pc only)
**GRUB_TERMINAL=console**

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
**GRUB_GFXMODE=1920x1080**

そこで、モニターを接続し、これらの設定を上記のファイルに適用しました。モニターを取り外してボードの電源を入れると、ロードするだけで、1つを除いてすべて正常に動作します。 Remminaとvnc-viewerを使用したグラフィカル接続が非常に遅いです!私は今どうすればいい?

個人的には、現在の構成では、ボードはデスクトップ画像の転送にグラフィカル処理ユニットを使用していないため、グラフィカル接続が遅いと思います。

sshを使用すると、すべてが問題なく、scpを使用してファイルを高速(約6〜10メガバイト/秒)で転送できるため、ネットワークが原因であるとは思いません。

2
Parsa

カーネルの一部の進化を追跡しなかったため、あなたの問題について明確な考えがありません。ただし、問題に直面する場合は、テストの目的で解像度のサイズを徐々に減らします:正しい値(vbeinfoを使用)で多くのテストを行いますが、小さなステップで、最大800x600または640x480にします。提供した情報だけで、多くのバグ、ボードのファームウェアのバグ(ハードウェアの回復方法は説明しませんでした)、および/またはグラフィックスボードのドライバーのバグが疑われます。私が行うことをお勧めする別のテストは、ubuntuまたはknoppixの古いライブCDでPCをブートし、何をしたかをテストすることです。古いディストリビューションの選択は、Linuxカーネルがグラフィックボードの「特別なハードウェア」機能を使用しないようにすることです。

1

これがローカルネットワーク上にある場合は、常に X11転送 を試すことができます。 Xプロトコルはより「おしゃべり」ですので、待ち時間が長い接続を使用している場合は、かなり遅くなります。ただし、問題がネットワークではなくVNCにある場合は、試してみる価値があります。

1
MilkeyMouse