Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!nic.cerf.net!bdavis From: bdavis@nic.cerf.net (Barry Davis) Newsgroups: comp.dcom.modems Subject: Re: USR Courier V.32bis questions etc.... Message-ID: <350@nic.cerf.net> Date: 24 Apr 91 15:31:34 GMT References: <6465@husc6.harvard.edu> <1991Apr21.032236.21724@netcom.COM> Organization: CERFnet; La Jolla, CA Lines: 56 In article <1991Apr21.032236.21724@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: > [deleted] > I think the reason most modem manufacturers are creating modems with a max > RS232 speed of 38400 are doing it for three reasons: (a) It doesn't require > exotic, costly processors, (b) Real life data transfers won't be more than > 2.7:1 compressible 98% of the time, and (c) Few computers can handle data > rates above 38400 bps. In short, they're designing a modem that will meet > your data transfer needs without exceeding your budget needs. I agree wih (a) and (b), but (c) should be qualified to include Terminal Servers. With more and more LANs including terminal servers which CAN do 38.4 kbps on more than one port at a time, like the Emulex Performance Series Server (blatant plug...), having a 38.4 kbps interface and hardware (RTS/CTS) flow control doesn't hurt. Although 19.2 kbps is probably good enough for V.32bis applications with compression, the extra speed is a selling point for MIS people looking to get the most for their money. The issue in terminal servers running above 9600 bps serial port rates is one of load balancing. There are on-going debates as to whether an interrupt driven or polling scheme provides the best throughput. I believe that integrated multi-I/O boards are largely interrupt based (ie ALMs, Systechs, etc.). This is the main reason for terminal servers, offloading the high speed interrupt traffic from the CPU to a dedicated device on the LAN. Terminal servers using interrupt schemes provide quick processing of async data into IP datagrams during interactive sessions to a network host. But, this interrupt scheme causes a sudden degradation of server performance in the presence of bulk data applications such as WAN use. In the implementation of SLIP/CSLIP/PPP on terminal servers, a polling scheme seems to work better. This polling scheme looks at the serial ports at intervals determined by an internal counter/timer. Two lists are used to keep track of idle and active ports, the active ports receiving priority in the polling scheme. While the inherent latency of this polling scheme may cause problems in time critical applications that require a very short round-trip time, it does not cause a problem to interactive sessions since the round-trip time rarely exceeds 100 msec. This polling scheme will also assure that there is an even degradation, load balancing, on all ports of the server. This will happen as async traffic builds, but will take longer to occur than in an interrupt based I/O scheme. I am obviously biased towards a polling scheme due to the fact that I use my server for dial IP applications in which bulk data is the norm. But, once again, the extra speed and hardware flow control come in very handy for this type of application, if the modem can do them reliably. =============================================================================== Cerafin E. Castillo ______ ______ TCP/IP LAN/WAN Connectivity \ / INET: cec@emulex.com EMULEX Corporation ______ \/ ______ 2880 Zanker Rd., Suite 204 /\ UUCP: uunet!emulex!cec San Jose, CA 95131 ______/ \______ (408) 452-4777 E M U L E X "Beauty does what Beauty does best; it's Beautiful!" ================================================================================