Xref: utzoo comp.unix.aux:1410 comp.unix.questions:17939
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!ira.uka.de!smurf!urlichs
From: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Newsgroups: comp.unix.aux,comp.unix.questions
Subject: Keeping up with 19200 baud
Message-ID: <1219@smurf.ira.uka.de>
Date: 17 Nov 89 21:13:51 GMT
Reply-To: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Organization: University of Karlsruhe, FRG
Lines: 26

I have the following problem with my Macintosh II, running A/UX 1.0 (S5R2):

When receiving 19200 baud data with uucp-g, the speed is OK at first. Then
things start to deteriorate; it seems that uucico doesn't get processor time
when its read is complete but some time afterwards (about 1/5 to 1/10 second).
As soon as I start a disk-intensive job, uucico's speed goes up, then down
again a few seconds after the disk intensive job is completed. (I used
find / -name vgztw ;-) 

nice(-20) doesn't do anything except that the speed drops off somewhat slower.
ps shows a NICE of zero (obviously) and PRI goes up to 70 rather fast.
It also shows a C parameter of 10.
This seems to indicate that the scheduler thinks my uucico is CPU-bound when
in reality it is emphatically not. (Sending goes ahead at full speed which I
can't explain because it should not make a difference to the scheduler
whether I send a block of 64 bytes and read one of five, or the other way
round).

What can I do?
Can I (comp.unix.questions question) access the kernel's process structure in
kernel memory and set the PRI and/or C values back to something "reasonable"?
Any sample code to access the proc table which actually works? :-)

Or (comp.unix.aux question) is that problem fixed in A/UX 1.1?

aTdHvAnKcSe
-- Matthias Urlichs, urlichs@smurf.ira.uka.de