home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 4842 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.0 KB
  1. Path: sparky!uunet!gatech!psuvax1!rutgers!igor.rutgers.edu!athos.rutgers.edu!hedrick
  2. From: hedrick@athos.rutgers.edu (Charles Hedrick)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: [386BSD]
  5. Message-ID: <Aug.29.15.45.59.1992.3059@athos.rutgers.edu>
  6. Date: 29 Aug 92 19:46:00 GMT
  7. References: <p5tullo@sgi.sgi.com> <Btr5F5.AJ9@pix.com>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 46
  10.  
  11. stripes@pix.com (Josh Osborne) writes:
  12.  
  13. >But I don't think 386BSD _currently_ has support for PPP, or AX.25 (and
  14. >there may be a few other things 386BSD doesn't have), also NOS seems to
  15. >lose way fewer charactors at high speeds.  Hopefully we can fix all that,
  16. >but for the moment "NOS is not needed" isn't quite true...
  17.  
  18. Character loss is normally in the device-level code.  If you're using
  19. a normal PC serial interface, the kernel must respond to an interrupt
  20. for each character before the next is ready.  At 9600 bps this
  21. requires an interrupt latency somewhat less than 1 msec.  It took
  22. several months of tweaking the I/O on Linux to get SLIP to work
  23. reliably there on a slow machine.  Moving the actual TCP
  24. implementation into the kernel would not have helped.  Indeed it may
  25. make things worse, as there's more code in the kernel that could
  26. potentially slow down interrupt latency.  I don't know how 386BSD is
  27. doing its interrupt handling, but the most likely problems would be
  28. that code called from the clock interrupt handler (which could include
  29. all the TCP protocol processing if somebody wasn't careful) could be
  30. taking longer than 1 msec to complete).  That's because the clock is
  31. the device that's most likely to be at a higher priority than the
  32. serial interrupt.
  33.  
  34. It is by no means clear to me that doing TCP in the kernel is going to
  35. result in the best performance with SLIP.  KA9Q under Linux with VJ
  36. header compression gives interactive response that feels like a
  37. terminal (except when I let the modem use MNP5, when I can feel the
  38. delay caused by that protocol).  Under SunOS 4.1.1 with the standard
  39. kernel SLIP implementation I find SLIP painful.  Of course Sun has
  40. notoriously bad serial handling, so it may be that 386BSD will do
  41. better.  But if you think about how the data is being handled, how
  42. many context switches are being done, etc., it's not obvious to me
  43. that there's a performance advantage to doing TCP/IP in the kernel.
  44. Where it does win is in the ability to run TCP application from
  45. multiple processes.  Thus you can have telnet sessions in several
  46. windows, servers that are independent of your telnet sessions, etc.
  47. This is obviously a great advantage, and certainly justifies doing the
  48. kernel implementation.  But for a PC at home, where you want a couple
  49. of telnet sessions and some FTP's now or then, the advantage is not as
  50. dramatic.  Depending upon how carefully the implementors have thought
  51. about interrupt handling, you could actually get better performance
  52. with KA9Q for SLIP.
  53.  
  54. This posting seems to imply that 386BSD is losing characters in SLIP.
  55. Even with a 368SX/16, there is no reason that you should ever lose
  56. characters, if your interrupt handling is properly done.
  57.