home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / 5873 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  2.4 KB
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!rdsunx!barnett
  2. From: barnett@grymoire.crd.ge.com (Bruce Barnett)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Why would a Sun take 1.5 seconds to retransmit a missed packet?
  5. Message-ID: <BARNETT.93Jan8142235@grymoire.crd.ge.com>
  6. Date: 8 Jan 93 19:22:35 GMT
  7. References: <184841@pyramid.pyramid.com>
  8. Sender: usenet@crd.ge.com (Required for NNTP)
  9. Reply-To: barnett@crdgw1.ge.com
  10. Organization: GE Corp. R & D, Schenectady, NY
  11. Lines: 42
  12. In-Reply-To: lstowell@pyrnova.mis.pyramid.com's message of 7 Jan 93 20:34:04 GMT
  13. Nntp-Posting-Host: grymoire.crd.ge.com
  14.  
  15. In article <184841@pyramid.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
  16. >      Transmitting using what protocol?   FTP, NFS copy or what?
  17.  
  18. It's TCP based. Similar to FTP.
  19.  
  20. >>Packets are missed by the archive system, so the Sun has to retransmit
  21. >>the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
  22.  
  23. >   Those are pretty typical numbers for TCP layer time-outs...
  24.  
  25.  
  26. Thomas Narten mentioned that the granularity of the retransmit timer
  27. is a multiple of 0.5 seconds. Also for every ACK of one segment sent,
  28. you have to restart the timer for the next segment.
  29.  
  30. I wonder if a finer granularity on the retransmit value would help if
  31. the peer is on the same network? I guess this is tough because some
  32. peers may be slow and some may be fast. It could keep track of the
  33. time for an ACK and try to pick a timeout near that time, I guess.....
  34.  
  35.  
  36. >     If this is FTP, you'd probably be better off getting rid of the
  37. >     fatal collisions on the net.....unless you can set the time-outs
  38. >     to a very small number (very dangerous, but....)
  39.  
  40. It's not collisions, because I saw the packets being sent.  It seems
  41. the receiver _missed_ seeing the packets on Ethernet. People have told
  42. me the best solution is to upgrade the receiver. This could be a
  43. hardware upgrade (faster CPU, more memory, more ethernet ports,
  44. smarter ethernet ports, etc.) and possibly some software tuning. Does
  45. anyone have advice on the relative advantage of each option? How much
  46. would more memory help? A faster CPU? A second CPU? A second Ethernet
  47. card?  A faster disk? What is the best choice? The most cost-effective
  48. choice? Who's gonna win the Superbowl? Well, forget the last question.
  49. I was on a roll..... :-)
  50.  
  51.  
  52. Thanks for all of the advice, esp. Stephen C. Trier, Aaron Leonard,
  53. Thomas Narten, Anay Panvalkar, Paul Hyder, and Roger-Hunen.
  54.  
  55. --
  56. Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
  57.