SunOS4.1.3 to Solaris 2.3?

SunOS4.1.3 to Solaris 2.3?

Post by Ronald Elliott, 88 » Sat, 02 Jul 1994 04:27:18



Forgive me if these questions have been answered previously, since I have not
been reading this news group.

We are considering "upgrading" to Solaris 2.3 from SunOS 4.1.3.  What kind of
problems can be expected?

What experiences have people had concerning SunOS 4.1.3 and Solaris 2.3 with
multiprocessors?  Does Sun OS4.1.3 seem to work with multiple processors?  How
are resources such as ethernet, RS-232, etc. handled?

Thanks in advance.   RonE

=======================================================
| Ron Elliott                          |              |
| Mail:  Martin Marietta Technologies  | Any opinions |
|        PO Box 555837  MP-140         |  expressed   |
|        Orlando, FL 32855             | are strictly |
| Phone: (407) 356-8878                |   my own.    |

=======================================================

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by Da » Sun, 03 Jul 1994 09:12:12




> Forgive me if these questions have been answered previously, since I have not
> been reading this news group.

> We are considering "upgrading" to Solaris 2.3 from SunOS 4.1.3.  What kind of
> problems can be expected?

I'm am not a Sun guru, but from my understanding the SunOS is based on BSD
UNIX.  Solaris 2.3 is based on SVR4.  This is a major difference in
software compatability, and day to day operation.  Also, administration of
Solaris is  different than SunOS.

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by Charles Hedri » Sun, 03 Jul 1994 11:09:45



Quote:>We are considering "upgrading" to Solaris 2.3 from SunOS 4.1.3.  What kind of
>problems can be expected?
>What experiences have people had concerning SunOS 4.1.3 and Solaris 2.3 with
>multiprocessors?  Does Sun OS4.1.3 seem to work with multiple processors?  How
>are resources such as ethernet, RS-232, etc. handled?

It depends upon the configuration and task.  For some systems, 2.3
would work fine.  On any desktop slower than a SS10, it's likely to
feel painfully slow, particularly in less than 24 MB of memory.  On a
lightly or moderately loaded SS10 or above, with enough memory, 2.3
should be fine.  For machines with lots of users (certainly over 100),
think *very* carefully before moving to 2.3 or earlier.  [There's one
exception to the comment about desktops.  The OpenWindows server
shipped with 4.1.3 is very slow.  We don't see this because we use the
MIT X server.  The OpenWindows server shipped with 2.3 is a lot better
than 4.1.3.  So if you're using Sun's OpenWindows, the improvement in
the X implementation in going from 4.1.3 to 2.3 may make up for the
fact that the OS is a lot slower.  However this is only likely to
happen if you have lots of memory.]

You might want to wait for 2.4.  We've been sticking with 4.1.3 for
most systems, but we're probably going to take the plunge with 2.4.

The primary problem with multiple processors under 2.3 is that select
and poll are not fully symmetrized in 2.3 and earlier.  This is
supposedly fixed in 2.4.  The effect is that telnet and similar
network code can't effectively make use of multiple processors in
versions older than 2.4.  Of course 4.1.3 isn't symmetrized at all.
To a first approximation, you're going to lose under 4.1.3 with N
processors if you're got more than 1/N% system time (as shown, e.g. in
vmstat).  In practice normal timesharing seems to work fine with 2
processors under 4.1.3.  Compute-bound stuff works even with 4
processors.  There have been a number of reports of trouble with
general timesharing loads on 4 processors.  Typical timesharing loads
have a bit more than 50% system time.  So with more than 2 processors,
you have big trouble under 4.1.3.  Other than that, 4.1.3 works fine
for us with multiple processors.  (The only problems we seen with our
MP systems under 4.1.3 are the standard problems with 51 processors.
But we see that with single processor systems too, and we think the
fix works just as well for MP sysems as SP systems.)

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by Rob McMah » Sun, 03 Jul 1994 22:38:38




>The primary problem with multiple processors under 2.3 is that select and
>poll are not fully symmetrized in 2.3 and earlier.  This is supposedly fixed
>in 2.4.  The effect is that telnet and similar network code can't effectively
>make use of multiple processors in versions older than 2.4.

Have you any more details on this, it sounds interesting.

Rob
--
UUCP:   ...!mcsun!uknet!warwick!cudcv   PHONE:  +44 203 523037

Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by Casper H.S. D » Sun, 03 Jul 1994 23:03:22





>>The primary problem with multiple processors under 2.3 is that select and
>>poll are not fully symmetrized in 2.3 and earlier.  This is supposedly fixed
>>in 2.4.  The effect is that telnet and similar network code can't effectively
>>make use of multiple processors in versions older than 2.4.
>Have you any more details on this, it sounds interesting.

% nm /kernel/unix | grep poll_lock
[1818]  |4028031856|       8|OBJT |GLOB |0    |6      |poll_lock

What else is there to know?

Casper

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by John DiMar » Fri, 08 Jul 1994 02:55:58



>For some systems, 2.3
>would work fine.  On any desktop slower than a SS10, it's likely to
>feel painfully slow, particularly in less than 24 MB of memory.  On a
>lightly or moderately loaded SS10 or above, with enough memory, 2.3
>should be fine.  

That's not been our experience. We found our IPCs felt as spritely or more so
running Solaris 2.3 than they did running SunOS 4.1.1 (both running X11R5),
depending on what was being done. However, the Solaris 2.x kernel seems to
gobble up about 4MB of memory more than the 4.x kernel.

Note: spriteliness of feel in Solaris 2.x depends on how you tune your
scheduler. The default tuning in 2.3 is fairly reasonable, except that it
breaks nice. We rolled our own. Note: the 4.x scheduler isn't tunable.

Certain applications (eg. ld) seem to require more memory in Solaris
2.3 than they did under 4.x. Since software developers seem to run things
like ld quite a bit (which is no surprise), more memory for them seems
in order.

A good rule of thumb: start with the amount of memory you needed for 4.x,
add 4MB, and add another 4MB if the machine is being heavily used by software
developers.

Quote:>The primary problem with multiple processors under 2.3 is that select
>and poll are not fully symmetrized in 2.3 and earlier.  This is
>supposedly fixed in 2.4.  The effect is that telnet and similar
>network code can't effectively make use of multiple processors in
>versions older than 2.4.  Of course 4.1.3 isn't symmetrized at all.
>To a first approximation, you're going to lose under 4.1.3 with N
>processors if you're got more than 1/N% system time (as shown, e.g. in
>vmstat).  In practice normal timesharing seems to work fine with 2
>processors under 4.1.3.  Compute-bound stuff works even with 4
>processors.  There have been a number of reports of trouble with
>general timesharing loads on 4 processors.  Typical timesharing loads
>have a bit more than 50% system time.  So with more than 2 processors,
>you have big trouble under 4.1.3.  Other than that, 4.1.3 works fine
>for us with multiple processors.  (The only problems we seen with our
>MP systems under 4.1.3 are the standard problems with 51 processors.
>But we see that with single processor systems too, and we think the
>fix works just as well for MP sysems as SP systems.)

There are a few issues that are all mixed together here that need to be
distinguished. Firstly, there's the question of how the multiprocessing
implementations of Solaris 2.x and SunOS 4.1.x compare. Secondly, there's
the question of multiprocessing support for SuperSPARC under SunOS 4.1.x.
Finally, there's the question of how individual applications can take
advantage of multiprocessing.

Addressing the first question, Sun added multiprocessing support to 4.1.2
(and later) so that they could ship the 600 series (with two or four Ross 601
processors) with an OS that worked (Solaris 2.x was far from being stable at
the time). Rather than multithread the 4.x kernel (a difficult and
time-consuming task), they simply set up a kernel mutex to ensure that only one
processor can run kernel code at a time (note: all processors are treated
equally, so this actually is, contrary to popular rumour, a form of symmetric
multiprocessing). This was relatively simple to implement, and offers
reasonably good performance in some circumstances, but deteriorates when many
processes want to delve into the kernel at once. (Think four *agers, one
bathroom.) In practice, 4.x multiprocessing works well for single-user
machines with long-running compute-bound background tasks, and fairly
decently for large timesharing machines with two processors. Adding another
two processors to a large timesharing machine provides some improvement, but
not as much as would be expected. This is what Charles is discussing in the
middle of the above paragraph.

Solaris 2.x, on the other hand, has a multithreaded kernel, which permits
several processors to run kernel code at once. For timesharing workloads, it
tends to get quite a bit more out of four processors than 4.x does.

As for the second question, Sun does not officially support multiprocessing
using SuperSPARC processors in SunOS 4.1.x. However, the multiprocessing
code is pretty much independent in the kernel from the processor-specific
code, and if you try multiple SuperSPARCs in a SS10, SS20, or 600 series
machine, it will more-or-less work. However, Sun management (for non-technical
reasons) decided not to test and verify multiple SuperSPARCs under 4.1.x.
This means that it may well be buggy (it's difficult to get MP cache coherency
right, and the SuperSPARC caches are quite different from the cache used by
the Ross 601), and those who do this do so at their own risk. Some people have
chosen to take the risk, and run their systems this way. We don't, ourselves.

Finally, the third question: individual applications can take advantage of
multiprocessing under 4.x only by making use of several processes (using fork
and exec), which are assigned to different processors automatically by the
kernel. This scheme works for Solaris 2.x too, but 2.x also offers a
user-level threads library which can be used to multithread a single process.
However, for a library call to be effectively used by a multithreaded
process, it must be re-entrant (i.e. if one thread makes a library call
before another has finished making the same call, things must work properly).
In 2.3, the socket library (where the "select" call may be found) is not
re-entrant, I believe, which is what Charles is referring to at the beginning
of his paragraph.

Regards,

John
--


University of Toronto                                     EA201B,(416)978-1928

 
 
 

SunOS4.1.3 to Solaris 2.3?

Post by John DiMar » Fri, 08 Jul 1994 08:11:29



Quote:>In 2.3, the socket library (where the "select" call may be found) is not
>re-entrant, I believe, which is what Charles is referring to at the beginning
>of his paragraph.

Oops, I goofed. This is quite wrong. My apologies.

select (and most of the socket library, in fact) is, in fact, MT-safe in 2.3.
That's what I get for not reading the fine manual. :-(  It's Solaris 2.2 (and
previous) which doesn't have a MT-safe socket library.

The problem with select and poll that Charles was referring to is the fact
that poll locks a global structure in the kernel whenever it checks its
file descriptors, which means that only one processor at a time can do this.
This isn't good on a big timesharing multiprocessor, where many processes
are waiting - using poll (or select, which is implemented using poll) - for
many different users.

Regards,

John
--


University of Toronto                                     EA201B,(416)978-1928