home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / 5846 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  1.5 KB
  1. Path: sparky!uunet!gossip.pyramid.com!pyramid!lstowell
  2. From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
  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: <184841@pyramid.pyramid.com>
  6. Date: 7 Jan 93 20:34:04 GMT
  7. Sender: daemon@pyramid.pyramid.com
  8. Reply-To: lstowell@pyrnova.pyramid.com.pyramid.com (Lon Stowell)
  9. Organization: Pyramid Technology Corporation
  10. Lines: 26
  11.  
  12. In article <BARNETT.93Jan7091846@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes:
  13. >I am examing some data collected from a medical network, and noticed
  14. >some unusual timings.
  15. >
  16. >A Sun is transmitting large files (3.5Mbytes average) to an archive 
  17. >system while receiving images from a scanner.
  18.  
  19.    Transmitting using what protocol?   FTP, NFS copy or what?
  20.  
  21. >
  22. >Packets are missed by the archive system, so the Sun has to retransmit
  23. >the missed packets. I have noticed large delays (0.5 - 1.5 seconds)
  24.  
  25.    Those are pretty typical numbers for TCP layer time-outs...
  26.  
  27. >
  28. >Why would there be such a long delay? I would expect the data is in
  29. >mbufs, so the time to resent the missed packets should be small. 
  30. >From the timing it looks like the data was occasionally on a disk.
  31. >If we wanted to remove these conditions, am I correct in assuming the
  32. >sending system needs more RAM or perhaps more buffers?
  33.   
  34.   If this is FTP, you'd probably be better off getting rid of the
  35.   fatal collisions on the net.....unless you can set the time-outs
  36.   to a very small number (very dangerous, but....)
  37.  
  38.