On 6/17/11 11:50 PM, Lorenzo Fiorini wrote:
>> Can you verify that the connection is not using session encryption
>> (GnuTLS)? That's the only thing I could imagine that could be causing a
>> slow-down.
>
> I read about this but how can I check this?
>
> This is the xinetd entry:
>
> service vnc1024
> {
> disable = no
> socket_type = stream
> protocol = tcp
> group = tty
> wait = no
> user = nobody
> server = /usr/bin/Xvnc
> server_args = -desktop server -inetd -query localhost -geometry
> 1024x768 -DisconnectClients -NeverShared -depth 24 -once
> -securitytypes=None
The -SecurityTypes argument disables it, so apparently you aren't using
encryption (or authentication, either.) Normally, if you're using some
form of password authentication, the password entry dialog will display
the type of encryption/authentication being used. You can also get this
information by popping up the session information dialog once connected.
> It was the Ubuntu Karmic repositories' xvnc4viewer which reports RealVnc 4.1.x
>
> I tried hextile because it was the protocol reported by vncviewer with
> the old server and
> I've read that Tight is more sensible to the client speed.
> The clients are PII 350Mhz 96MB with 3Com 3c905B card and ethtool reports
> 10Mbit Half/duplex.
Those are some awfully slow clients. I'm still going to vote for Tight
being the best method, however, because your network is also really
slow. Anything except Tight is likely to be fully network-constrained
on that configuration, which would equate to ~0.7-0.8 Mpixels/sec for
Hextile or Raw and ~2 Mpixels/sec for ZRLE. Tight can theoretically
squeeze 8-9 Mpixels/sec out of the network, if the client CPUs can
decode the JPEG fast enough. That's a big if, though, on nearly
15-year-old technology. I'm trying to rack my brain as to the relative
speed of the old PII's relative to the PIII and P4 chips I first started
using for remote motion-JPEG work, and what I'm coming up with is that
your chip is probably limiting you to about 5-6 Mpixels/sec. Still
theoretically better than any of the other protocols, though.
(NOTE: all of the above makes some fairly big-- and likely erroneous--
assumptions about the types of applications you're running and the types
of images they generate.)
The long and the short of it is: if there is a slow-down in Hextile on
TigerVNC vs. RealVNC, I can't seem to repro it. Raw is definitely
slower, though, which I consider to be a bug in our implementation.
Unless you were using Raw, I have no idea why you're experiencing a
slow-down with TigerVNC.
I guess the next question would be: what exactly is your workload, and
how are you measuring performance?
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Tigervnc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tigervnc-users
