Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!gatech!psuvax1!rutgers!igor.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.bsd Subject: Re: [386BSD] Message-ID: <Aug.29.15.45.59.1992.3059@athos.rutgers.edu> Date: 29 Aug 92 19:46:00 GMT References: <p5tullo@sgi.sgi.com> <Btr5F5.AJ9@pix.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 46 stripes@pix.com (Josh Osborne) writes: >But I don't think 386BSD _currently_ has support for PPP, or AX.25 (and >there may be a few other things 386BSD doesn't have), also NOS seems to >lose way fewer charactors at high speeds. Hopefully we can fix all that, >but for the moment "NOS is not needed" isn't quite true... Character loss is normally in the device-level code. If you're using a normal PC serial interface, the kernel must respond to an interrupt for each character before the next is ready. At 9600 bps this requires an interrupt latency somewhat less than 1 msec. It took several months of tweaking the I/O on Linux to get SLIP to work reliably there on a slow machine. Moving the actual TCP implementation into the kernel would not have helped. Indeed it may make things worse, as there's more code in the kernel that could potentially slow down interrupt latency. I don't know how 386BSD is doing its interrupt handling, but the most likely problems would be that code called from the clock interrupt handler (which could include all the TCP protocol processing if somebody wasn't careful) could be taking longer than 1 msec to complete). That's because the clock is the device that's most likely to be at a higher priority than the serial interrupt. It is by no means clear to me that doing TCP in the kernel is going to result in the best performance with SLIP. KA9Q under Linux with VJ header compression gives interactive response that feels like a terminal (except when I let the modem use MNP5, when I can feel the delay caused by that protocol). Under SunOS 4.1.1 with the standard kernel SLIP implementation I find SLIP painful. Of course Sun has notoriously bad serial handling, so it may be that 386BSD will do better. But if you think about how the data is being handled, how many context switches are being done, etc., it's not obvious to me that there's a performance advantage to doing TCP/IP in the kernel. Where it does win is in the ability to run TCP application from multiple processes. Thus you can have telnet sessions in several windows, servers that are independent of your telnet sessions, etc. This is obviously a great advantage, and certainly justifies doing the kernel implementation. But for a PC at home, where you want a couple of telnet sessions and some FTP's now or then, the advantage is not as dramatic. Depending upon how carefully the implementors have thought about interrupt handling, you could actually get better performance with KA9Q for SLIP. This posting seems to imply that 386BSD is losing characters in SLIP. Even with a 368SX/16, there is no reason that you should ever lose characters, if your interrupt handling is properly done.