[comp.windows.x] Xkernel

stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (12/06/90)

Summary Worth the trouble?

We were briefly considering Xkernel around here for our old 3/50's,
which are now running SunOS4.1 and have become unbearably slow when
running standalone X (mostly through the dynamic linking business,
we believe).

It turns out just firing up Xsun at boot time and then managing the
display through a remote xdm also gives you very respectable `X terminal'
performance.  My question is: does anynbody have a comparison between
that kind of configuration and Xkernel, regarding X display performance?
Is it really worth the trouble downgrading the machine to Xkernel?

I'm asking because we figured our current configuration has at couple of
advantages:

- No special installation/administrative procedures required.
- Can switch back to a SunView machine easily (yes, we still have
  people using SunView, and its performance did not suffer as 
  dramatically with the 4.1 upgrade as X's).
- Since Xsun is generally not overloading the machine you can even use it
  to rlogin to it and do other useful stuff (such as compiles)  while
  somebody is using it at an X terminal.  In most cases there is no noticable 
  performance degradation.

Any comments?

-- 
Andreas Stolcke
International Computer Science Institute	stolcke@icsi.Berkeley.EDU
1957 Center St., Suite 600, Berkeley, CA 94704	(415) 642-4274 ext. 126

stripes@eng.umd.edu (Joshua Osborne) (12/14/90)

In article <1990Dec5.214857.13863@agate.berkeley.edu> you write:
> Summary Worth the trouble?
> 
> We were briefly considering Xkernel around here for our old 3/50's,
> which are now running SunOS4.1 and have become unbearably slow when
> running standalone X (mostly through the dynamic linking business,
> we believe).

Compile a staticly linked set of X programs, your already poor throughput will
become really *really* poor (on a 4Meg system at least).

> It turns out just firing up Xsun at boot time and then managing the
> display through a remote xdm also gives you very respectable `X terminal'
> performance.  My question is: does anynbody have a comparison between
> that kind of configuration and Xkernel, regarding X display performance?
> Is it really worth the trouble downgrading the machine to Xkernel?

Yes.  The speed increse mesured with xbench and xstone is slight, this
is because they do a large number of the same thing in a row.  This
reduces the apparent cost of paging.  Few clients programs work like this -- generally, they have a much larger mix of operations in the course of
execution of a client program.

> I'm asking because we figured our current configuration has at couple of
> advantages:
> 
> - No special installation/administrative procedures required.

Actually it is very easy to deal with 3/50 X terminals, we set up ten in
one hour (including a very cool hack mentioned below).  Of course, we
aready have another lab (of VAXen) running the same way so we had 3 SPARCs
already set up to xdm for everyone.  The setup for running xdm is probably
the most difficult part of the entire show.

> - Can switch back to a SunView machine easily (yes, we still have
>   people using SunView, and its performance did not suffer as 
>   dramatically with the 4.1 upgrade as X's).

We have the 3/50 normal boot path set to le(0,0,0), the diag boot path is
le(0,0,0)/Xunix.  Xunix is the X kernal set to run /etc/Xnit instead of
/etc/init (we used emacs to do the bit surgery).

A flick of the diag switch and users can plod into SunView, a flick it back
and you have a fraction of a 4/65 on your desk!  (normally a large fraction,
but worst case is 1/10th around here).

Oh yeah, I lied.  You need to reboot between switch flipping.

By the way for SunOS 4.1 the memory requirements of the SunView stuff was
reduced, that may be why you think "SunView performance did not suffer as
dramatically with the 4.1 upgrade as X's".

> - Since Xsun is generally not overloading the machine you can even use it
>   to rlogin to it and do other useful stuff (such as compiles)  while
>   somebody is using it at an X terminal.  In most cases there is no noticable 
>   performance degradation.

When I have used Thorin (one of our 3/50s) as an X workstation (ie running
Xsun on top of normal SunOS) in the past, the only times Xsun wasn't using
100% of the CPU was when I was doing nothing, or during pageing.  The
overhead from various daemons seemed minimal, but I haven't done
a real study (yet)...

> Any comments?

Xkernels for 4M 3/50s are a big win.  I think they wouldn't be on a 8M 3/50.
They are *not* a win on 8M 3/60s w/ cgfour displays.  All workstations I
used for the test were dickless.  Oh, yeah a VaxStation 2000 is passable
(just barely) as an X terminal, it rots as a workstation.
(at least diskless 6M memory VS2000 b&w display rots as a workstation)
-- 
           stripes@eng.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
"Don't over-comment"     - p151 The Elements of Programming Style 2nd Edition
                                   Kernighan and Plauger

adam@metaware.metaware.com (At these prices, I can't NAME names) (12/18/90)

>Xkernels for 4M 3/50s are a big win.  I think they wouldn't be on a 8M 3/50.
>They are *not* a win on 8M 3/60s w/ cgfour displays.  All workstations I
>used for the test were dickless.

Were those Unix workstations? #-)
-- 
adam margulies                                    metaware incorporated
                                                  INTERNET: adam@metaware.com
                                                  UUCP:     uunet!metaware!adam
                                                  ATT:      (408)429-META x3016

sarima@tdatirv.UUCP (Stanley Friesen) (12/19/90)

In article <1990Dec14.001146.3131@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes:
>In article <1990Dec5.214857.13863@agate.berkeley.edu> you write:
>> ... which are now running SunOS4.1 and have become unbearably slow when
>> running standalone X (mostly through the dynamic linking business,
>> we believe).
 
>Compile a staticly linked set of X programs, your already poor throughput will
>become really *really* poor (on a 4Meg system at least).

I would like to emphasize the truth of this.  I, too, believed that the
dynamic linkng was a speed problem, until we got FrameMaker 2.1X from Frame
Technologies.  That monster is statically linked.  True, shelltool takes a
longish time to *start*, but once it is running it is quite good.  Maker
on the other hand starts slow and then generates a paging fit whenever I
switch from one activity to another.  Talk about *sloooow*!  (Frame Technology
are you listening? - at *least* make xlib and libc dynamic linking!)

-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)

bret@codonics.COM (Bret Orsburn) (12/20/90)

>>All workstations I used for the test were dickless.
>
>Were those Unix workstations? #-)

No, Eunuchs.

	       :-)


-- 
-------------------
bret@codonics.com
uunet!codonics!bret
Bret Orsburn