Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!news.crl.dec.com!jg
From: jg@crl.dec.com (Jim Gettys)
Newsgroups: comp.windows.x
Subject: Re: A tirade about inefficient software & systems
Message-ID: <1990Nov5.153646.23855@crl.dec.com>
Date: 5 Nov 90 15:36:46 GMT
References: <9011040724.AA03335@Larry.McRCIM.McGill.EDU>
Sender: news@crl.dec.com (USENET News System)
Reply-To: jg@crl.dec.com (Jim Gettys)
Organization: DEC Cambridge Research Lab
Lines: 52

In article <9011040724.AA03335@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU writes:
> X uses more network bandwidth, except in very atypical applications.
> This is a disadvantage for the X approach.  (Again, I haven't done any
> tests, so I can't say how much more.)

I've never seen any real data; until I do, I treat all claims that other systems
send fewer bytes with scepticism.  To date, all I've ever seen is marketing claims.
Some real data for real applications would be very interesting.  The X11 protocol is
much more byte efficient than earlier versions of X were.

In any case, remember that on a local net, if it takes longer to compute the
byte than to send it, you've suffered a net performance loss.  The X protocol was carefully
designed to be very very easy to process, for maximum performance.

Over low speed links, one should use an X protocol compressor; such things
exist, and optimize link bandwidth at the expense of CPU time overhead, the correct
choice for such situations.

> 
> One difference which is not a philosophical difference, but is still
> significant, is that X is available entirely free.
> 
> Another non-philosophical difference, which again is significant: X is
> far more widespread.  (This is, I believe, due in large part to its
> being available free.)
> 
> The first two are, IMO, advantages for X.  There is only one server,
> but many clients, often on many machines.  When the client machine is
> not the server machine, the client machine will typically be the
> "bigger" (more memory, faster cpu, etc) of the two.  In the case where
> the client and server are known to be on the same machine, and
> portability is not a consideration, an all-singing-all-dancing server
> may indeed be a better way to go.

Huh?  With shared libraries, and the fact that communications are typically
faster on the same machine?  I don't see that the conclusion follows.  And the biggest
argument for such servers is to make interaction with the user as close as possible
to reduce latencies; on the same machine, this argument is specious.  On the
same machine, a cycle is a cycle is a cycle, unless overhead is increased by the
choice of where to do the computation.

> 
> (Network bandwidth does not worry me.  Networks are fast and getting
> faster: 10Mbps is so common you find it in dorm rooms nowadays, with
> fiber (80Mbps? 100Mbps?) in regular use, and higher rates coming down
> the pike.  In any case, at least to my mind, it's heavily outweighed by
> the advantages.)
> 

Agreed.  X's design center is campus area networking.  We are in the middle of
installing FDDI here to our workstation, for example.
					- Jim Gettys