kdq@demott.com (Kevin D. Quitt) (02/07/91)
We are currently using Motorola's Delta 3000 series machines (25MHz
68030), and we generally like them, but we've stumbled onto a problem.
It appears that Motorola's UNIX buffers pipes onto disk, and our product
is about to crash and burn because the pipes are so slow. The problem
surfaced recently when we a) moved from "development" type systems to
"production" systems (with slower, cheaper disks), and b) started driving
systems with more control channels.
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. Since these systems are often turned off at night, and
restarted in the morning (and they live on the factory floor), this
translates to the system not coming up as often as not.
I need one of two things: A SYSV UNIX that will run on Motorla's
hardware, or a new box. We need:
68030, 25MHz+
4MB+ RAM
100MB+ disk (doesn't need to be *very* fast, 30ms+ seek is OK)
12+ serial ports
Any pointers, happy users? Thanks in advance.
--
_
Kevin D. Quitt demott!kdq kdq@demott.com
DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266
VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP lastheiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (02/08/91)
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
dig@peritek.UUCP (Dave Gotwisner) (02/08/91)
In article <1991Feb6.182148.14806@demott.com>, kdq@demott.com (Kevin D. Quitt) writes: > > We are currently using Motorola's Delta 3000 series machines (25MHz > 68030), and we generally like them, but we've stumbled onto a problem. > It appears that Motorola's UNIX buffers pipes onto disk, and our product > is about to crash and burn because the pipes are so slow. The problem > surfaced recently when we a) moved from "development" type systems to > "production" systems (with slower, cheaper disks), and b) started driving > systems with more control channels. Actually, all UNIX systems that I have ever dealt with (from Version 6 through SVR3 and 4.3BSD) have put pipes on disk, usually in the root filesystem. This is a standard UNIXism. If this is not acceptable for your environment, you can (a) buy SVR4 source and rewrite the pipe code, or (b) rewrite your applications so they don't use pipes. Obviously (b) is easier. If you are running lots of programs and piping in the shell, you are probably out of luck, but if you have several of your own programs which are communicating, you may want to use the shared memory interface rather than pipes to communicate between your machines. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
doug@letni.lonestar.org (Doug Davis) (02/08/91)
In article <1646@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >Actually, all UNIX systems that I have ever dealt with (from Version 6 through >SVR3 and 4.3BSD) have put pipes on disk, usually in the root filesystem. This >is a standard UNIXism. If this is not acceptable for your environment, you can >(a) buy SVR4 source and rewrite the pipe code, Bzzzzzt BING! In SVR4 Pipes are stream based. Also a couple of SVR3's implmented pipes via streams as well. doug __ Doug Davis/4409 Sarazen/Mesquite Texas, 75150/214-270-9226 {texsun|lawnet|smu}!letni!doug doug@letni.lonestar.org "Be seeing you..."
paul@taniwha.UUCP (Paul Campbell) (02/09/91)
In article <1646@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >In article <1991Feb6.182148.14806@demott.com>, kdq@demott.com (Kevin D. Quitt) writes: >> >> We are currently using Motorola's Delta 3000 series machines (25MHz >> 68030), and we generally like them, but we've stumbled onto a problem. >> It appears that Motorola's UNIX buffers pipes onto disk, and our product > >Actually, all UNIX systems that I have ever dealt with (from Version 6 through >SVR3 and 4.3BSD) have put pipes on disk, usually in the root filesystem. This >is a standard UNIXism. If this is not acceptable for your environment, you can Actually neither of these statements is strictly true, what Unix does is it grabs a few disk buffers to put the pipe's buffered information in before it's read. If the consuming task waits around for too long before grabbing the data the buffers will get flushed out to disk because someone else wants to use them (or because sync comes along). Usually the pipe is busy enough that the data is flowing though it without making a trip to disk. If your system is busy doing lots of other disk IO (which may cause your pipe bufferes to be flushed to disk more) and you have a time critical application you might have to think about using another IPC mechanism like sockets or messages or shared memory/semaphores any of which will probably do the job and wont involve disk IO. Another possibility is to increase the size of the buffer cache. This way of storing pipe info is sort of a poor man's VM (and a neat hack on the part of the original implementors).. Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P 'Where do you find a "kinder gentler nation" when you need one these days?' The proper solution to this mess is to lock Bush and Hussein in a room - and throw away the key - that way everyone can go home.
louie@sayshell.umd.edu (Louis A. Mamakos) (02/10/91)
>>Actually, all UNIX systems that I have ever dealt with (from Version 6 through >>SVR3 and 4.3BSD) have put pipes on disk, usually in the root filesystem. This >>is a standard UNIXism. If this is not acceptable for your environment, you can >>(a) buy SVR4 source and rewrite the pipe code, >Bzzzzzt BING! In SVR4 Pipes are stream based. Also a couple of SVR3's >implmented pipes via streams as well. Bzzzzt BING! (again). Certainly in 4.3BSD, and probably in 4.2BSD pipes were implemented in the kernel using the socket abstraction with in-memory socket buffers. In fact, it was very similar to socketpair() in the underlying implementation. louie
bernie@metapro.DIALix.oz.au (Bernd Felsche) (02/19/91)
In <1646@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >In article <1991Feb6.182148.14806@demott.com>, kdq@demott.com (Kevin D. Quitt) writes: >> >> We are currently using Motorola's Delta 3000 series machines (25MHz >> 68030), and we generally like them, but we've stumbled onto a problem. >> It appears that Motorola's UNIX buffers pipes onto disk, and our product >> is about to crash and burn because the pipes are so slow. The problem >> surfaced recently when we a) moved from "development" type systems to >> "production" systems (with slower, cheaper disks), and b) started driving >> systems with more control channels. >Actually, all UNIX systems that I have ever dealt with (from Version 6 through >SVR3 and 4.3BSD) have put pipes on disk, usually in the root filesystem. This >is a standard UNIXism. If this is not acceptable for your environment, you can >(a) buy SVR4 source and rewrite the pipe code, or (b) rewrite your applications >so they don't use pipes. .... You forget that pipedev is a configurable device, where you can define major and minor device numbers. If you write a ram-disk device driver, then that can be assigned to pipedev and things should move a bit quicker. I note that the original query was regarding a small-memory system (4MB?), so the pipedev would be tiny. Nevertheless, fast and adequate for most embedded systems. -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au