home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5621 < prev    next >
Encoding:
Text File  |  1992-09-12  |  1.5 KB  |  35 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!usc!sdd.hp.com!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn
  3. From: karn@servo.qualcomm.com (Phil Karn)
  4. Subject: Re: [386BSD]
  5. Message-ID: <1992Sep13.061916.27672@qualcomm.com>
  6. Sender: news@qualcomm.com
  7. Nntp-Posting-Host: servo.qualcomm.com
  8. Organization: Qualcomm, Inc
  9. References: <4ebZONa00WB3Qzp15W@andrew.cmu.edu> <1992Aug29.163711.25695@NeoSoft.com>
  10. Date: Sun, 13 Sep 1992 06:19:16 GMT
  11. Lines: 22
  12.  
  13. In article <1992Aug29.163711.25695@NeoSoft.com> karl@NeoSoft.com (Karl Lehenbauer) writes:
  14. >Unless you want to do ham packet radio stuff, the Berkeley TCP/IP and SLIP
  15. >implementations that come with 386BSD are superior to KA9Q, which was
  16. >designed for non-multitasking DOS operation and, thus, incurs some serious
  17. >penalties when running under Unix.
  18.  
  19. Ahem.
  20.  
  21. Although I agree that my stuff isn't designed to run efficiently under
  22. UNIX, I beg to differ about the "quality" of the implementation. I've
  23. long had all the same stuff in my TCP/IP and SLIP that Berkeley has:
  24. VJ header compression, VJ srtt/mdev rto calculation, clamped
  25. retransmission backoffs, slow start, fast recovery, Nagle tinygram
  26. avoidance, etc. It's fast enough to never be the bottleneck on a FTP
  27. (as opposed to the wire or the disk.)  And it has avoided many of the
  28. problems that still nag the descendants of some previous Berkeley
  29. TCPs, like closing all TCP connections to a given host whenever you
  30. receive ANY ICMP message that references that host...
  31.  
  32. Phil
  33.  
  34.  
  35.