home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mips / 869 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.3 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!swrinde!elroy.jpl.nasa.gov!usc!noiro.acs.uci.edu!gordius!gordius!bruce
  2. From: bruce@gordian.com (Bruce Hafford)
  3. Newsgroups: comp.sys.mips
  4. Subject: R4000 & Mips OS 5.0b = horrid TCP behavior??
  5. Keywords: R4000,TCP/IP
  6. Message-ID: <1992Aug12.223059.28974@gordian.com>
  7. Date: 12 Aug 92 22:30:59 GMT
  8. Sender: news@gordian.com
  9. Organization: Gordian
  10. Lines: 40
  11.  
  12. Well, we finally got our new Mips R4000 station booted and
  13. happy.  Except for having the wrong Xwindows version, but that's
  14. another story.  Anyway, we're seeing some gross TCP/IP behavior
  15. and are wondering if anyone else has noticed this.
  16.  
  17. There seem to be 3 (possibly interrelated) problems:
  18.  
  19. 1) WAY too many plain TCP ack packets.  If the R4000 is generating
  20. data to a Telnet user, for example, it will follow a slew of data packets
  21. with a slew of ACKs, even though the user did not send anything
  22. that needs acking.  These acks number 10-25 at a time, spaced at
  23. about 700usec - 1.5 msec apart.  disgusting!
  24.  
  25. 2) Unbuffered data output.  On the above user, the R4000 generates data
  26. packets (~50 bytes each) every ~1msec.  Slower TCP clients get
  27. completely swamped, and quickly fall behind.  Buffering the output
  28. is sorely needed, if only for 2-5 msec.  Or at least dynamic modification
  29. of the output timer intervals?
  30.  
  31. Between items 1 & 2, the packet ratio ends up with the R4000 sending
  32. about 6-7 times as many packets as the listener.  OS 4.52 on a Magnum 3xxx
  33. end up about 1.5 - 2 times as many, if that.
  34.  
  35. 3) Bogus retransmissions?  We have a couple products here that do
  36. not keep up with the R4000's TCP rate, and thus fall behind and drop
  37. packets.  The R4000 seems to handle retransmissions ok sometimes, 
  38. but several times the session has completely stopped dead because
  39. the 4000 did NOT retransmit the correct packet.  The other TCP node 
  40. continued to ack up to that dropped packet, but the 4000 never
  41. resends it.  Needless to say, incorrect as far as we can tell.
  42.  
  43. If these things are tunable in the OS, that's fine, but having the
  44. default be "too many packets, dropped retransmits" seems wrong-ish.
  45.  
  46. So - anyone else out there using the R4000 and new 5.0b Mips OS?
  47. Have you seen anything like this?  email or post - I'll summarize
  48. if people are interested.  And if any Mips engineers happen to
  49. run across this, feel free to contact us!
  50.  
  51. bruce@gordian.com
  52.