[General Topics] Menneisyys:
1.2.2.6 VNC Bandwidth usage fine tuning

With a capable VNC client / server combo, you can fine-tune the bandwidth usage and force it to be really small – almost as small as with GoToMyPC in high/true color modes. This, however, requires you to know what options there are.

First, there are so-called "encodings" used with VNC. Some of them really love wasting bandwidth; for example, RAW, which, as you may already have guessed, just sends over uncompressed raw screen data and, consequently, takes orders of magnitude more bandwidth than protocols utilizing compression methods. Well-known, high-bandwidth and, therefore, to-be-avoided encodings also include RRE and CoRRE.

The widely used Hextile (the best available with the above-introduced, not recommended three free, "legacy" clients) is already a bit better but still consumes a lot of bandwidth and should, therefore, be avoided. With some additional compression (Zlib hextile, for example) it becomes pretty usable, bandwidth-wise: it will "only" consume about three times more bandwidth than RDP or more advanced (for example, JPEG-based) VNC encodings. Of the Pocket PC clients, only Mocha (and, of course, PT PO) supports Zlib / ZRLE compression.

Finally, Tight with or without JPG (the best, most space/bandwidth-efficient way to encode images) is by far the most effective VNC encoding. Of the Pocket PC-based clients, only PT PO supports Tight / JPG.

While CopyRect isn't strictly an encoding form but a way to tell the client "just scroll some of the old screen contents instead of downloading it again", it should be pointed out that it must always be enabled to (in cases - see for example the smooth scrolling examples below -, greatly) reduce bandwidth usage.

Other tips for PT PO: you may freely decrease the, by default, 1.0s update delay to say, 0.3 s - it will have almost no adverse effect on the bandwidth usage.

1.2.2.6.1 Server-side scaling issues

In addition to choosing the right encoding (at least Zlib / ZRLE and, preferably, Tight (JPG)), you should also know what server-side scaling is and how you can fine-tune it to further reduce bandwidth usage.

First, remote desktops are, generally, bigger than the resolution of your Pocket PC screen. For example, my notebook has an UXGA (1600*1200) screen, which is far larger than even the VGA screens of some of my Pocket PC's. If (and only if!) you don't zoom into this image fully and scroll around the page so that a pixel on the remote desktop equals to a pixel on the Pocket PC, you can make use of clever desktop-side (!) rescaling of screen images before (!) returning them to the client. Just imagine: if you would like to just navigate on a 1600*1200 desktop with your VGA screen, by instructing the server to resize the screen images returned to the client itself, you can save a LOT of bandwidth. For example, if the server uses the rescaling factor 2, then, it'll send over 1600/2 * 1200/2, that is, 800*600 images, which are still bigger than the VGA screen and, therefore, onlly result in very small image quality degradation - while delivering considerable bandwidth usage decrease. Using the scaling factor 3 with the above-mentioned UXGA desktops, the full screen images sent over will become 1600/3 * 1200/3; that is, 533*400 in size. Of course, this will introduce some kind of blurriness - but the bandwidth advantage will be considerable.

Note that, currently, VNC servers are only capable of using integer scaling factors - that is, you can't. This is why you can't just tell them "with a UXGA remote desktop and a VGA client, use the rescaling factor 1600/640, that is, 2.5 so that you get the most optimal result with the best possible image quality".

Some real-world benchmark results to show all this (PTeSVNC server, 1600*1200 desktop, VGA portrait client, Tight NO JPG, server scale 1:2; all data are in Mbytes; the smaller, the better):

CLICK HERE for the VNC chart!

In Landscape, using the above configuration (UXGA desktop, VGA client), using UltraVNC, some other benchmark results:

Server scale 1:4, no smooth: 310k

Tight JPG max speed, server scale 1:2: 550k

Tight JPG HQ, server scale 1:2: 570k

Tight No JPG, server scale 1:2: 560k

Tight No JPG, server scale 1:1: 780k

Finally, SVGA (800*600) desktop, VGA landscape client, with smooth scrolling on:

1:2 Server Scale on: 1.33

Scale off: 1.95

As can be seen, server-side scaling, while it does introduce some kind of blurriness (example screenshots of this later), really reduce the used bandwidth: with a two-factor server-side resizing, about 35..45%. Also, as can be seen, fine-tuning the JPEG quality parameters (or, for that matter, completely disabling it) in Tight mode of PT PO doesn't really result in considerable bandwidth savings.

Finally, some examples of the quality degradation:

1:1

1:2

1:3

1:4

As can clearly be seen, the quality slightly degrades even at the rescale factor of two. That is, there is a clear tradeoff between quality and speed. You will want to use / configure the server-side scaling feature in VNC clients (.NET Viewer and PT PO) that directly allow for configuring this wisely.

1.2.3 Other applications

1.2.3.1 z2 Remote2PC 1.2 build 1205 by z2 Software

z2 Remote2PC is a very famous Pocket PC remote controlling solution. It is generally really solid and its only problem is the definitely higher bandwidth consumption compared to most other alternatives. It doesn't support HTTPS either; in a fully firewalled environment, it may prove less useful than Web-based solutions like LogMeIn, I'm InTouch and GoToMyPC. It does support callbacks to combat this, but the latter requires some manual configuration and, in this mode, can't be used with also-firewalled clients. If these aren't an issue (you won't be, for example, accessing your desktop via slow and/or expensive lines and won't trey to access your firewalled servers from an also firewalled/NAT'ed client), I highly recommend this application.

Reviews, threads: Thread on 1.0 (note that some users call it even faster than TSC – this is certainly not the case); PocketNow. Also see this and this

1.2.3.2 pcAnywhere 12.0 by Symantec

The PPC version is 2.0.0 build 121; note that the 2.0.1 update refuses to run. The trial 12 beta download (direct link here and here. Megathanks to akheron for the latter link!). The Mobile client CAB is also available here; I haven’t tested this myself.

This is another all-in-one remote controlling solution. While it does have its strengths (for example, clipboard synchronization, which is only supported by very few other solutions, and connections even through serial links - that is, not necessarily TCP/IP-based ones), in general, I can't really recommend this solution. Remote controlling / access-wise, there are much more sound, powerful solutions with a much better price/performance ratio and bandwidth utilization (another area pcAnywhere doesn't really excel at).

Example screenshots: After, on the desktop, starting Start / Programs / Symantec pcAnywhere, you’re presented this dialog. Here, you can connect to other computers, start file transfer (as can be seen, file transfer, as with all the other Pocket PC and unlike some desktop solutions, must be initiated from here and not from a remote desktop session) and start hosting.