Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!quest!ssb
From: ssb@quest.UUCP (Scott Bertilson)
Newsgroups: comp.sys.3b1
Subject: Re: 19.2K on a 3b1
Message-ID: <1991Apr04.144939.587@quest.UUCP>
Date: 4 Apr 91 14:49:39 GMT
Article-I.D.: quest.1991Apr04.144939.587
References: <10499@uwm.edu> <2214@public.BTR.COM> <1991Mar27.033750.29895@ceilidh.beartrack.com>
Distribution: na
Organization: Quest Research, Inc.
Lines: 47

In article <1991Mar27.033750.29895@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes:
>9600, but ONLY if I kill off my ethernet before the transmission starts.  If
>ethernet is running, I get lots of 75cps & less, and frequent failures

  Well, I find it very interesting that you say killing your Ethernet
makes things work better, because I've had no problems running "async_main"
to tty000 with V.32/MNP-5 at 19200 *UNTIL* I tried to do it with MGR
running.  Please note that I say "with MGR running"...I don't even
have to run the terminal manager under MGR.  Someone suggested that
MGR was too CPU-intensive to run a terminal emulator, so my second
test was to "Suspd" myself to another "wind.o" window and run the
terminal emulator..which normally shuts down MGR and drops you into
a shell in the window you left.  That worked just fine, so I then
tried the following:
	1) "Suspd" to a spare window
	2) "Suspd" back to the MGR window
	3) Enter "sleep 5; exit" so that the shell will
	exit and fire up MGR after 5 seconds
	4) "Suspd" back to the spare window and be ready
	to enter "clear" to hide the MGR gunk
	5) Run the terminal emulator and note that it
	now loses characters.
If I delete steps 2-4, I find that HDB "cu" or "async_main"
works just great.
  I don't know that much about the internals of MGR, but I
am inclined strongly to believe that the only thing it is
doing when "idle" but alive is calling "select".  I'm
convinced that somewhere in "select" there is a long critical
section run with interrupts blocked, but I can't figure out
where it is.  The fact that Ethernet exhibits the same symptoms
leads me to believe that this is an insurmountable problem
inherent in applying the "select" wart to our SysV hog.  (I
assume that BSD on VAXen solves it using the NETISR code,
but I haven't had access to BSD kernel source for a number
of years so I can't see how they make "select" work better.)
I've wondered if one might be able to solve this problem by
carefully applied optimizations to "select", but I don't know
what part of the code to concentrate on and haven't had time
to experiment until I figured out.
----
			Scott S. Bertilson
			ssb%quest.UUCP@cs.umn.edu
			scott@poincare.geom.umn.edu
-- 

Scott S. Bertilson   ...ssb@quest.UUCP
			scott@poincare.geom.umn.edu