19.2K on a 3b1 (serial patch query)

[Kris A. Kugel]

In articles <2225 at public.BTR.COM> and <35907 at ditka.Chicago.COM>,
thad at public.BTR.COM (Thaddeus P. Floryan) and kls at ditka.Chicago.COM
(Karl Swartz) disagree over whether the 3b1, HFC, and 19200baud
get along together.  Thad says he has a vanilla 3.51m.

I remember recently installing the kernel serial patch, which
is supposed to make serial i/o work "better" by checking for
serial interrupts more often.

I've included some relevant quotes from the original article below.
I believe that I got this from osu-cis, rather than the original posting.

+ From: steveb at shade.UUCP (Steve Barber)
+ Newsgroups: unix-pc.general,comp.sys.att
+ Subject: Kernel Patch to Improve Serial Line Response Time (update)
+ Date: 15 Apr 90 06:15:25 GMT
+ Reply-To: steveb at shade.ann-arbor.mi.us (Steve Barber)
+ Organization: Ripley Computing/Consulting Services (Ripley, MI)
+ 
+ Back in December, Gene Olson (gene at digibd) posted information explaining
+ how to patch your 3.51a kernel to allow it to move characters from the
+ raw interrupt queue to the raw input queue every 1/60th of a second,
+ rather than every 4/60ths of a second as the code in the kernel is written.
+ The rest of this article is an update to Gene's original article
+ explaining how to make the change to the 3.51m kernel.  (Yes, due to
+ the MeterMaid code, the addresses are different.)
+ 
+ I should add a few comments here regarding the use of this code, now
+ that I've been running this way for a while:
+ 
+ 
+ 4) My friend whose Sun I'm now connected to used to have a 3B1.  When we
+    applied this patch to both of our machines, our average UUCP transfer
+    rates jumped from around 750 bytes/sec to almost 1400 bytes/sec.  When
+    only one machine of the two had the patch, average transfer rates were
+    around 1000 bytes/sec, but presumably the machine with the patch could
+    read data at 1400 bytes/sec, and the other machine was still reading
+    at 750 bytes/sec, thus causing the average to be 1000 bytes/sec.
+ 
+ 5) Just as another data point in the hardware flow control issue (please
+    don't start another argument out of this!):  I've been using hardware
+    flow control on 19200 ports on my 3b1 since OS 3.51.  For the most part,
+    it works.  uucp works great that way, and in fact due to the packet
+    nature of the g protocol, I seem to recall that it doesn't end up needing
+    to use the flow control much anyway.  The only problems I've noticed
+    have been when I'm logged in with cu over a 19200 serial line with
+    flow control.  Occasionally there are lost characters and sometimes I
+    suspect (during a long ls, for instance) that sometimes I lose more like
+    a few lines than a few characters, but I've never worried about it too
+    much.  pcomm 1.1 handled the speed with no problem, but 1.2 seems to lose
+    some characters now and then too.  (That and the feeble vt100 emulation
+    slows it down a lot.  I may just comment that out.)

(remainder of article deleted)
This sure sounds like it could explain the difference
between Thad and Karl's machines.

Could you two let the rest of us know if you are using these patches?
At least that will make it clear if we are talking about a difference
in machines or kernels.

                               Kris A. Kugel
                             ( 908 ) 842-2707
                      uunet!tsdiag.ccur.com!hico2!kak (maybe)
                        {daver,ditka,zorch}!hico2!kak
                      internet: kak at hico2.westmark.com