Slow graphical remote connection in linux

Question

I've installed Ubuntu Desktop 16.04 on my computer. When I connect the motherboard to the monitor and turn the board on, everything works fine.I configured the vino (Desktop Sharing) on the board so I can connect to it graphically using VNC, so I can connect to it locally in my network using VNC protocol (Remmina application or vnc-viewer).

but When I disconnect it from the monitor and turn the board on, it doesn't load any operating system and I can't connect to it from local network! Even I can't find it in the local network using ping command!

I contacted the company I've bought the motherboard from and ask them about solution. they propose to change the grub configuration file in /etc/default/grub .

They told me to uncomment these two lines:

# 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**

So I connected a monitor and applied these settings to the file mentioned above. Now when I disconnect the monitor and turn the board on, it just loads and everything works fine except one thing. I have a very very slow graphical connection using Remmina and vnc-viewer! What should I do now?

I personally think that in the current configuration, the board doesn't use the graphical processing unit for transferring the desktop image so that's why I have a slow graphical connection.

using ssh, every thing is fine and I can transfer files using scp with high speed (around 6 to 10 Mbyte/sec), so I don't think it is because of network!

Solution 1

If this is on your local network, you could always try X11 forwarding. The X protocol is more "chatty," so if you are on a connection with a lot of latency it will be rather slow. However, if the problem lies with VNC and not your network, it could be worth a try.

Solution 2

I've no clear idea about your problem because I did not follow evolution of part of kernel. But if you would face your problem, I'd slowly decrease for testing purposes, the size of the resolution: make many tests with correct values (got with vbeinfo) but by smaller step, up to 800x600 or 640x480. Just with the information you give, I suspect many bugs, bug in firmware of your board (you did not explain how you recovered hardware), and/or bug in the driver of your graphics board. Another tests I suggest to do, is to boot your pc on old live cd of ubuntu or knoppix, and test what you did. The choice of old distribution is to be sure the linux kernel will not use "special hardware" features of your graphics board that could involve around your problem.

Comments

[Admin]

VNC itself very slow, even on fast network, so network not issue. GRUB is just loader, it not part of OS, even if it somehow related to issue, it weird bug, but I think it have very small chances. Also VNC is virtual buffer, so GPU is not need.

[Admin]

Your question is more appropriate on Super User, Server Fault or Unix & Linux. Of the 3, Super User or Unix & Linux are the most relevant, but it is also server related, just not a normal server issue.

[DeveloperACE]

i have experienced this slowness with remmina too. i know people who have switched from remmina to RealVNC's cloud-based solution and got way better performance. (i.e. from 1-5 FPS to like 15). I personally prefer not to use cloud based solutions for a connection i could make locally, and at this point im also wondering if the issue is remminas VNC plugin. will try something else and report back (if i remember)

[DeveloperACE]

Seems to be no appreciable difference between remmina and RealVNC viewer as a client to my eye (even on a wired/lower latency connection). next suspect is probably vino, the software ubuntu uses as a vnc server by default.

[Admin]

The other "benefit" of X forwarding is the windows from the remote machine appear as normal windows on the client by default (i.e. you don't have one giant window representing the remote's display).