Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!bnrgate!bcars223!fortinp
From: fortinp@bcars223.bnr.ca (Pierre Fortin)
Newsgroups: comp.os.minix
Subject: ST MINIX 1.1 Performance bug
Keywords: ST MINIX 1.1 Performance
Message-ID: <1081@bnrgate.bnr.ca>
Date: 19 Mar 90 07:16:33 GMT
Sender: news@bnrgate.bnr.ca
Lines: 41

While the problem I am about to describe occurs on ST 1.1, has anyone 
seen it on the PC version and/or any of the recent upgraded versions?

Using ST MINIX 1.1, I began the process of upgrading from the net postings.
Once I had all the original 1.5.0 postings on my HD, I figured this MINIX
sutff is multi-tasking, right?  All the postings were on my disk as: 00,
01, 02, ..., 73.  So I started typing in the following commands (I know,
I could use a shell script):

    uudecode 01 &
    uudecode 02 &
    uudecode 03 &
    uudecode 04 &
  etc.

Then things started to get REAL SLOW.  Before anyone jumps to conclusions
about "Yeah, but you're running all those processes...", here's something
to ponder...
Using the "ps" hot-key (Alt/Ctrl/F1), I noticed that usually one or two of 
these processes were using inordinate amounts of CPU time.  During the 
01-73 posting uudecodes, I found that all will eventually go to completion.
Once one of these processes is in this state (it may be the ONLY process
still running), it does I/O at the rate of about 1 per 8-10 seconds.  Also,
the CPU times which are usually in the low three-digit numbers climb to
16000+!!! units in the "sys" column.
 
I also noted that when two processes are in this state simultaneously, 
they will have alternating "flag" of 0 or 8, and one or the other will have
FS in the last column before the "command"; never both at the same time.

Killing the errant processes and restarting them usually runs fine.  
 
NOTE:  this problem is highly repeatable; entering enough commands also 
       produces the "try again" message.  The problem is NOT related with
       "uudecode", since I got the same thing (after re-booting) when
       running the resultant shells via "sh bawk_00", "sh bawk_01", etc.
 
Is this a known problem?  Has it been fixed in the recent postings?
 
Pierre Fortin
fortinp@bnr.ca