On Sat, 2005-11-05 at 02:41, Gilboa Davara wrote:
> > > In short, unless I can: A. Find what's bothering VNC, B. Get FreeNX
> > > working on x86-64 machines. Hummingbird (Exceed) is about to get a nice
> > > paycheck :/
> >
> > I don't see how one brand or another X server is going to make
> > any difference. The network traffic will be the same unless
> > they have some way to cheat and disable the scan. Forcing
> > compression on freenx would help at the expense of load on
> > the server.
>
> Here's the deal, the problem is *not* network traffic.
> The server are connected to GbE switched network, and the network
> utilization is fairly low.
X uses a lot of bandwidth and more importantly has a lot of
back-and-forth chatter for every operation that needs very
low latency. If the problem is the CPU hit with the real-time
AV scan on network traffic or some network issue that
causes packet loss like a duplex mismatch on a switch
connection, you'll see big problems with any version of X.
VNC doesn't have the back-and-forth chatter per operation
and should just be a bandwith/throughput issue, but because
it works with bit images it will never be quite as responsive
as X. If you see problems other than slight slowness with
VNC with the AV scan off, you almost certainly have some
network problem. See if you can find some throughput
tests that use UDP so you can detect packet loss.
Freenx is optimized for X traffic more than VNC and once
it is installed it is convenient to use, but you shouldn't
need it if you have a reasonable network.
> > Dual-boot into Linux? Run Linux native and terminal services
> > for windows apps? Linux native with vmware player for
> > windows in a virtual machines? All of these would let you
> > use your CPU for more than scanning the network for viruses.
> >
>
> I doubt that the power's to be will be willing to try such a radical
> solution.
> At least for now, Windows is our (or actually their's) main development
> environment.
If you have another Linux box, that would be a reasonable
comparison against Cygwin. Try running corresponding
remote X sessions linux/linux and Cygwin/linux, preferably
over the same connection. If you see the same problems, it
is the network, if not it is something windows-related but
probably not just Cygwin/X because I see close to equivalent
performance.
--
Les Mikesell
lesmikesell@xxxxxxxxx
