Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!rutgers!topaz.rutgers.edu!ron From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.dcom.lans Subject: Re: Terminal servers over ethernet? Message-ID:Date: 7 Jul 88 17:51:49 GMT References: <320@ucrmath.UUCP> <3960@saturn.ucsc.edu> <9816@e.ms.uky.edu> <23612@bu-cs.BU.EDU> <9870@g.ms.uky.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 30 > Oh puhlease ...when will people STOP making bogus assumptions like this? If you'd read the damn context you quoted, you'll see that it isn't a bad assumption to make. I had also stated that reasonable terminal servers have enough power to statistically multiplex your terminal traffic onto the Ethernet without doing flow control. This was a direct counter to the claim that the original poster could not even get 1200 baud to work. For devices that are going to run a protocol that isn't internally regulating like TCP, you will need flow control. Good devices support many different types of flow control. For example, the CISCO termianl servers have a couple of different flavors of software and hardware flow control. If you are spec- ing performance on a box and you are hooking terminals to it, then why buy enough capacity for 9600 baud bidirectional traffic? > A case in point: SLIP service in a terminal server. > > If you have SLIP service there, it's very easy for the attached > computer to be generating large amounts of data and to start needing > flow control on the INPUT side of the serial port just as badly > as it is needed on the OUTPUT side. If you are trying to run slip "through" a telnet connection you're going to lose anyway. It's braindamanged. Why not buy a terminal server that does SLIP? Then you won't need flow control at all, any more than IP is doing for you anyway. -Ron