Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rutgers!mcdchg!heiby
From: heiby@mcdchg.chg.mcd.mot.com (Ron Heiby)
Newsgroups: comp.sys.m68k
Subject: Re: Need 68030 SYSV Box
Message-ID: <55920@mcdchg.chg.mcd.mot.com>
Date: 7 Feb 91 22:34:54 GMT
References: <1991Feb6.182148.14806@demott.com>
Organization: Motorola Computer Group, Schaumburg, IL
Lines: 54

kdq@demott.com (Kevin D. Quitt) writes:

>It appears that Motorola's UNIX buffers pipes onto disk

I'm surprised that you are seing a problem with this.  In most
applications that I've seen use pipes, the data in the pipe doesn't
have time to actually get written to the disk before being read out of
the pipe by the reading process.  Thus, the pipe write goes to the
file system buffer cache and the read (almost immediately) completes
from the same buffer, freeing it.  If your pipe blocks are actually
making it to the disk, it tells me that one or both of two things are
happening.  1) you have a very small file system buffer cache with
lots of file I/O.  2) your reading processes don't read from the pipe
until a fair amount of time has elapsed following the pipe write.

You haven't said what version of System V/68 you are using.  Current
is version 6.1.  Also, you don't say whether you are running any
networking, like TCP/IP.  You also don't say how much main memory you
have, although you imply that you have 4Meg when (later) you say that
you need "4MB+ RAM".  It may be that you would be better off with
8Meg.  Or, perhaps you could allocate more memory to the NBUF tunable
parameter (file system buffer cache).  With small memory systems, you
must be careful here to avoid starving the system for paging space in
main memory.  Another thing you might try is to use message queues
instead of pipes.  A lot depends on what kind of load you are seeing
on your system over-all and what kinds of "hot spots" exist.  I
recommend running "sar" while your application executes to help
provide pointers to what is happening in your system.

>    We've also had considerable problems with MVME332 card - it has an
>annoying tendency to fail to reset properly when the ambient temperature
>is 50F.

You don't say whether the problem is seen with a temperature of 50F
and up or 50F and below.  In either case, the board should operate at
50F.  In general, our boards are spec'd to operate at 0-50C (yes, C),
some requiring forced air cooling.

Also, why are you using the MVME332?  The MVME332XT is *much* better
for almost all applications, especially running System V/68, since the
on board processor handles UNIX tty termio(7) line disciplines,
reducing load on the CPU.  I'm pretty sure that the MVME332XT came out
at close to the same time as the MVME147, and a fair amount earlier
than the 25MHz version of the 147.  In any case, if you have a board
that is not operating correctly in our published temp range, which for
most of our current systems is 5-35 or 5-40 C, then you should contact
our Field Service Division and have the problem board replaced.

>    Any pointers, happy users?  Thanks in advance.

Hope I've helped with these pointers.  There are *lots* of happy users.
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"Wrong is wrong, even when it helps you." Popeye