From: drew@ladymacb.cs.colorado.edu (Drew Eckhardt) Subject: Re: Offical windows Date: 1 May 1992 12:42:58 GMT
In article <1992May1.085711.10120@csd.brispoly.ac.uk> cj_watts@csd.brispoly.ac.uk (Chris Watts) writes:
>In article <1992May1.082946.24540@csd.brispoly.ac.uk> d_smith@csd.bristol-poly.ac.uk writes:
>>
>>I use two 386's running Interactive System V, one is 25MHz and the other is
>>33. The 33 is quite snappy (not as good as the SPARC-based Solbourne S4000's
>>I also use) and the 25 is a bit slow at updating, but is perfectly usable.
>>The 25MHz has also only got 8Mb, wheras the 33 has 16. The 25 seems to
>>do a hell of a lot of swapping, wheras the 16 does hardly any.
>>
>>It's my theorey then, that X will be almost useless if you have less than
>>8Mb of memory, unless the code is very well optimised.
>>
>Actually its less than every one thinks.
>Acording to a book that I have just got it says that the best place to
^^^^^^^^^
>start for X windows is a 33Mhz 386 with at least 4MBytes ram and 100Mbytes
>disk space for all the executables.
>
This is VERY implementation specific. With small amounts of memory
(depending on the system, somewhere between 4 and 16M of memory),
the virtual memory system is CRITICAL, shared libraries can halve the
memory requirement for a small X client, and if you can't share
text pages, you are toasted. Remember, disk is 1000 times slower than
RAM. The xserver is also very important,
as well as underlying hardware. Graphics hardware with separate bitplanes
(ie, this would be _GA in a 16 color mode, or some of the HP displays),
can be VERY slow. On the other hand, I've seen opaque moves on
TSENG based 486's with vram.
In my experience :
1. 16M of memory on an RS/6000, running AIX 3.x, normal daemons (ie printer,
networking, etc), local disk, is intolerable. 32M is very reasonable.
2. 8M of memory on an HP9K series running a diskless Mt. Xinu
4.3 BSD is intolerable.
By intolerable, I mean the cursor, or xterms freezing when parts of
the X clients or X server are paged in from local disk, or NFS. Sometimes,
this delay can be measured in seconds, and the resulting lag between the
mouse pointer and the mouse movement makes menu selections virtually
impossible.
3. 8M of memory on a i486, running BSDI BSD Net 2,
Stock X server on a TSENG based board screams, and is
probably faster than our 16M, 50Mhz 400 series HP workstations
(1 bit, 1280 x 1024)
Also, what else will you do when running X? GCC2 will eat 1.5M of
RAM for itself, and if optimizing large programs may require
three times that.
100M of disk should be more than ample for running X under Linux.
From what little I've heard, Zorst has done an excellent job on
his X port, it will be testing RSN, and allegedly eats 6.5M
of disk for 'user' programs.
No matter how you look at it, after Linux allocated buffer cache,
init runs and spawns a few gettys, you have less than 3M of memory
in a 4M system. This is not enough.
>If you are going to have a window system on unix it would be best to have
>X windows since there is more support for X unlike other window systems I
>have heard of. It would also be easier to write you own programs using X,
>comparing the ease to create an X client comparing to a Dos windows3 program.
>
IMHO, the xt library is easier to program than windows SDK . However,
it is sort of an OO interface in 'C'. If you want simple
programming, you have to use a code builder on top, which will
have considerable overhead.
Also, remember that X is standard. You can pull Xasteroids,
Xantfarm, Xwhatever off of the net and have it work. You won't
find that sort of free software for ANY other windowing system,
MGR, or even MickeySoft Windoze.
>And putting a windows system in kernel would probabley slow the kernel down.
It doesn't slow things down. The kernel and window system can interact
in neat ways, making performance appear better to the end user. 8 1/2
isn't actually in Plan 9, but they're tightly integrated and performance
is incredible.
This is often done to convert old workstations into X terminals.
Sun 3/50's, 60's, etc make excellent X terminals when this is done.
On the otherhand, a certain manufacturer did this, and the results weren't
pleasant.