Xref: utzoo comp.sys.att:10576 unix-pc.general:6217
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!neoucom!wtm
From: wtm@uhura.neoucom.EDU (Bill Mayhew)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: My 3B1 FIXDISK 2.0 experience (so far, LONG)
Message-ID: <1990Oct10.111528.13746@uhura.neoucom.EDU>
Date: 10 Oct 90 11:15:28 GMT
References: <261@ramecs.UUCP> <1990Oct08.105551.28522@uhura.neoucom.EDU> <124@sialis.mn.org>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 29

One thing I should add is that my system has a voice power board in
the middle slot of the backplane.  I've noticed that if I run the
voice manager daemon that my average uucp transfers drop from about 
1400 char/sec to around 1200 char/sec (3.51).  The behavior is quite
repeatable by running setvm on, transferring a file, setvm off,
transferring a file then compare the results.  It is a bit puzzling,
as the voice manager should be spending most of its time sleeping,
and only needs to wake up in reponse to ring or off-hook event. The
ps command corroborates this, suggesting that voicemgr is not
executing a polling loop as indicated by the execution time.

The decrease in uucp performance I noticed the FIXDISK kernel was
about the same amount.  If I get a chance, I'll switch back to the
3.51m kernel without the voice power board to see if that makes a
difference.

True, the max uucp rate is only about 10 to 15 percent less, but I
do like the idea of saving on the order of 10 to 15 percent connect
time, especially for long distance calls.

I wasn't using the adb patch to change the UART polling rate on
either of the two respective kernel verisons.

==Bill==
-- 
Bill Mayhew      NEOUCOM Computer Services Department
Rootstown, OH  44272-9995  USA    phone: 216-325-2511
wtm@uhura.neoucom.edu   ....!uunet!aablue!neoucom!wtm
via internet: (140.220.001.001)