[comp.sys.3b1] RTS on hardware flow control

rhealey@digibd.com (Rob Healey) (03/26/91)

	Does anybody know how the 3b1 handles RTS when hardware flow control
	is on, i.e. does it lower RTS when it's input buffer is almost full
	and then raise it after the buffer has drained a bit?

	In a related question, does anyone know where in the kernel .o
	or cmb.o scheme of things where the hardware flow control code
	is? So as an industrious soul might try to fix it if it's broke...

	What the hey, any idea if it would be non trivial to add the
	code to do xon/xoff flow while hardware flow is on, i.e. reenable
	the ixon processing? There musta been a reason why they turned
	this off, anybody know what that reason is?

		 Thanks,

		-Rob

bruce@balilly (Bruce Lilly) (03/27/91)

In article <1991Mar26.065606.9989@digibd.com> rhealey@digibd.com (Rob Healey) writes:
>
>	Does anybody know how the 3b1 handles RTS when hardware flow control
>	is on, i.e. does it lower RTS when it's input buffer is almost full
>	and then raise it after the buffer has drained a bit?

Yes, although as others have noted, it doesn't work very well at high
speeds (after all there's only one processor, and if it's busy... RTS
might not be lowered in time to prevent overrun).

>	In a related question, does anyone know where in the kernel .o
>	or cmb.o scheme of things where the hardware flow control code
>	is? So as an industrious soul might try to fix it if it's broke...

I've looked at the cmb.o stuff, primarily to see how difficult it would be
to get the RS-232 ports to work in the expansion chassis -- the code's a
real mess.  I suspect (but can't say for sure) that the flow control stuff
is in the tty driver code in the kernel, rather then in the driver (since
it applies to the built-in port as well as expansion cards, that would be
the logical place for it).

>	What the hey, any idea if it would be non trivial to add the
>	code to do xon/xoff flow while hardware flow is on, i.e. reenable
>	the ixon processing? There musta been a reason why they turned
>	this off, anybody know what that reason is?

Basically, it's historical -- first there was only xon/xoff flow control;
HFC was tacked on later. BSD, for all of its faults, introduced a more
complicated termio structure (termios) with more bells and whistles (sound
familiar?), which has been folded into SVR4. According to the SVR4
manuals, one can have both hardware flow control and xon/xoff at the same
time. Also, RTC/CTS can be independently configured for input and output
hardware flow control (many other flexible options are available as well).
Sounds nice, but I'm sure there's a performance penalty.

As far as pumping a lot of data through the 3B1, I think the possibilities
are rather limited. With only a single processor doing everything, there's
just not enough raw power available. Frankly, the best configuration I've
seen has been a two-processor configuration, with one processor dedicated
to I/O (e.g. Sony News computers).  It seems a fairly elegant solution to
the I/O bottleneck, since there is a fairly clean split between the
top-level/low-level code for I/O. And having used the machines
occasionally, I must say that they are damned fast (of course, there are
problems... but nothing's perfect).  (try doing *anything* on a 3B1 while
reading/writing a floppy disk -- forget it -- everything slows down to a
snail's pace)
>
>		 Thanks,
>
>		-Rob

-- 
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM