Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ftpbox!mothost!motcid!murphyn
From: murphyn@motcid.UUCP (Neal P. Murphy)
Newsgroups: comp.sys.3b1
Subject: Re: The "Final" Word on 3b1 HFC
Message-ID: <7184@bone13.UUCP>
Date: 22 May 91 06:38:18 GMT
References: <1991May18.175656.2858@fithp> <1991May19.062144.25034@colnet.uucp>
Distribution: na
Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL
Lines: 19

res@colnet.uucp (Rob Stampfli) writes:

>Just to add another twist to the already sordid tale of woe regarding
>hardware flow control on the Unix-PC....

>I have a V.32 modem connected to my PC, and it seems to work just fine sans
>HFC with uucp g.  Well, almost -- it does tend to resync a lot when I am
>getting news, but I have always attributed that to the "known" problems of
>talking to a TB 2500 in V.32 mode.  The other day, I connected a terminal to
>another spare port.  Lo and behold, I discovered that any activity that
>resulted in significant output to the terminal completely hosed the uucp
>transfer in progress on the modem at the time.  I tried the following with

Just another thought: has anyone ever tried to set the nice(2) value of
the uucico process to, say, 10, where things usually run at 20? That might
give uucico more CPU time, give other processes less time, and cause
fewer buffer over-runs.

NPN