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