[Sunhelp] SGML tools on Solaris7 or non-GNUified Solaris

[James Lockwood]

On Mon, 22 Nov 1999, Gregory Leblanc wrote:

> I think I'm going to drag this out a little more, just to see how much
> education I can get.  :)

I'll give it one more shot, but this type of thing tires me out quickly.
Then again, hopefully this crowd will be a little more attentive than the
typical Usenet groupies.

> I'm aware that NFS is broken on Linux, which is bad.  And of course faster
> is always better, but I'm curious as to how extensively NFS is used, since I
> don't work in a unix shop.  If I'd taken the time to read the NFS howto, I
> might be using it on a couple of internal boxes, but I've heard that (rumor)
> NFS is rather insecure.  It seems to me that it should be able to make it
> secure, if it's like everything else on Unix, but I don't really know.  I
> guess I need to do a bit more reasearch.

NFS is as secure as the network you run it on.  What this means is open to
interpretation.

NFS is the lifeblood of most Unix networks.  Combined with client-side
caching (like cachefs) it makes managing very large networks of
workstations possible.

I was an RFS fan myself until BSD basically killed it off.  There are
definate advantages to going with a stateful approach, and the
transparency of remote device access was very appealing.

NFS is like X in many ways.  It sucks, but everything else so far has
sucked much worse.  SMB/CIFS definately falls into that category.

> > Much better IP stack.
> 
> I haven't seen this to be the case.  At home, I can pull about 40KB/sec from
> both my Linux box, and my Solaris box, over the same connection, which is a
> 384K DSL.  Windows 98 gets about 33-38, and NT usually gets 36-40.  But I
> see very little difference in these two IP stacks.  The linux IP stack also
> seems to have much more "added functionality" built in, so that you can do
> things like QOS and MASQ with the kernel tools.

First of all, 384kbps is a fairly slow line by modern standards.  Nearly
any modern IP stack can handle that, even my Sun 3/60 (running a stunning
20MHz 68020) could saturate it.

Secondly, IP stack performance is fairly constant with different
implementations when only a few connections per second are being made
(such as occurs with a single user on a client machine).  The performance
difference is most noticeable when a large number of different connections
with short lifetimes on a high bandwidth line are being handled, such as
on a web server.  The production Solaris IP stack is "properly"
multithreaded and handles high load gracefully, the Linux stack does not.

> > Finer kernel granularity.
> > Better kernel threading.
> 
> I don't understand kernel hacking yet, so I'll assume that those are "good
> things" that Solaris does better than Linux.

Correct.

The crudest kernel adaptation to SMP is to have a single jumbo lock around
the entire kernel, forcing only one instance of it to be run at any given
time.  This is how SunOS 4 and older releases of Linux did it.

The "better" way to do it is to have a larger number of locks protecting
different functions or data structures within a kernel.  This slows down
each kernel call a bit, but lets the kernel scale to an increasing number
of CPU's.

Linux and Solaris both do this, but Solaris does it much more heavily.
It takes a hit on smaller boxes but pays off on larger ones.

> > Fewer arbitrary limits (filesize, max open fd's, max memory, etc).
> 
> Well, the filesize limit is on it's way out, ext3 is running on a couple of
> servers that I know of, with good results.  The ram limit isn't for Intel
> hardware, since that's all the CPUs can address, except maybe the Xeon.  On
> SPARC this may be more of a problem, since they can easily handle much more
> RAM on a modern CPU than x86 can.  

Wrong.  Modern Intel h/w (Pentium Pro and above) has a 36-bit virtual
address space yielding a total addressable space of 64GB.  That was
introduced 4 years ago.

Linux limits the systemwide memory to that which can be directly addressed
by a register.  Other than 64-bit architectures (Alpha, Sparc V9) these
are in the minority.  I can have 16GB of RAM in a 32-bit CS6400 and
Solaris handles it fine.  Only 4GB is addressable by each process, but I
can run several 4GB processes simultaneously in RAM.

This is even an issue for machines with less than 4GB of RAM.  I might
want to have more than 4GB RAM + swap in order to fit a large working set
of code + data.  Examples include many processes doing mmap() on large
files, it's not as rare as you might think.

The open fd issue is IMHO more critical.

> > Stable driver interface (through the DDI).
> 
> I thought that the drivers for linux were generally pretty good, but I
> suppose I could be in error.  PCMCIA is maintained as a separate package
> from the kernel, and runs exclusively as modules.  That package seems to be
> at least as good as the one on MS, though I haven't tried Solaris on a
> PCMCIA computer yet.  That's the only example that I have, except that DPT
> (PC-RAID, and I hear this is what sun is using) writes their drives as a
> simple kernel patch.  I guess I need to take a few programming courses,
> since I'm only familiar with procedural programming, which doesn't make code
> that looks like what I've read.

Linux drivers are fairly good, but the interface still changes a bit from
time to time.  With the DDI you can change underlying characteristics of
the kernel as long as you provide equivalent functionality through the
interface.

> I don't suppose that these sort of things could be either kernel load time,
> or kernel compile time tweakable?  If they could then perhaps that might be
> a direction to point the linux kernel, although I have only a fringe
> knowledge of this, again.

It can be done, but it isn't easy.  It also wouldn't buy you much unless
you gave up some of the Solaris kernel multithreading at the same time.
This might net you faster syscalls, but less throughput when handling many
at one time.

-James