home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / comm / 12897 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  7.6 KB
  1. Path: sparky!uunet!news.claremont.edu!bridge2!buila.NSD.3Com.COM!msi
  2. From: msi@ESD.3Com.COM (Mark Isfeld)
  3. Newsgroups: comp.sys.mac.comm
  4. Subject: Re: VersaTerm SLIP Problems receiving data
  5. Keywords: SLIP VersaTerm transferring
  6. Message-ID: <msi.726865465@buila.NSD.3Com.COM>
  7. Date: 12 Jan 93 19:04:25 GMT
  8. References: <C0pLs0.GD3@ibeam.intel.com>
  9. Sender: news@bridge2.NSD.3Com.COM
  10. Lines: 179
  11. Nntp-Posting-Host: buila.nsd.3com.com
  12.  
  13. gweil@ibeam.intel.com (Garry Weil) writes:
  14.  
  15. >I have been having transferring problems, SLOW!, using VersaTerm FTP.
  16. >Small files transfer fast, under 20K, but larger files are very slow.
  17. >What I see watching my modem's LEDs is that there are bursts cycles
  18. >where FTP is receiving data, 10-20k, then the Send and Receive LEDs
  19. >go dark for 30 seconds upto minutes. A 200k file takes 20 to 30 
  20. >minutes to receive. To make this situation more interesting, I just
  21. >noticed that FTP sends FLY. The Send LED is almost always on!
  22.  
  23. >I have noticed this same problem using Fetch or trying to use a News
  24. >reader, Nuntius or NewsWatcher.
  25.  
  26. >My configuration:
  27. >1. Mac SE
  28. >2. System 7 with tune-up installed
  29. >3. Zoom 14.4k modem with compression and correction
  30. >4. Hardware handshaking modem cable
  31. >5. VersaTerm SLIP
  32. >6. MacTCP 1.1.1
  33. >7. Connected to an Annex terminal server running SLIP
  34. >8. MTU=1006
  35. >9. Sun4 FTP & NNTP server
  36.  
  37. >Is there any 'debug' thing I can do to help narrow down this problem?
  38. >What about a different MTU value? Modem configuration?
  39.  
  40. I had a very similar problem.  I strongly recomend setting the re-transmit
  41. filter to 0 to disable it.  
  42.  
  43. Background:
  44. Versaterm SLIP has a re-transmit timer that attempts to limit MACTCP's
  45. tendency to re-transmit too soon when dealing with a slow link like
  46. a SLIP modem link.  Essentially when MacTcp is transmitting data, it
  47. will re-send the same data too soon, since the acknowledge did not come
  48. as soon as it expected (latencies over a SLIP modem compression line
  49. are quite long, even if the packets are small).  So Versaterm Slip provides
  50. a "patch" that deletes any identical transmit packets that appear within 
  51. a particular window of time.  This process works quite well for 
  52. "uploading" data from your MAC to another system.  It achieves nearly full
  53. line rate transmitions.
  54.  
  55. The problem is that in some configurations, Versaterm SLIP appears to have
  56. a bug.  When data is being recieved, and none is being sent, MacTcp is
  57. only transmitting Acknowledges.  Versaterm Slip appears to delete the 
  58. second and subsequent acknowledges, as though they were duplicate 
  59. re-transmitions (indeed they have the same Sequence numbers since no
  60. data is being transmitted, Versaterm should also check the Ack field which
  61. is changing).  
  62.  
  63. So the sequence goes something like this.
  64.  
  65. REcieve     Transmit
  66. ------      --------
  67. Packet 1
  68. packet 2       ACK1
  69. packet 3        ***  Ack2 should appear here but does not
  70. packet 4        ***  Ack3 should appear here but does not
  71. packet 5        ***  Ack4 should appear here but does not
  72.                 ***  Ack5 should appear here but does not
  73.  
  74. About this time the Sending devices window closes, and there is a pause 
  75. (typically 30 seconds). Then the sending device starts re-sending the 
  76. data that appears to be lost.
  77.  
  78. REcieve     Transmit
  79. ------      --------
  80. Packet 2
  81. packet 3       Ack5 In response to packet 2 MacTcp sends the current Ack
  82.                which is Ack 5
  83. packet 6
  84. packet 7
  85. and so on.
  86.  
  87.  
  88. If You set the Re-transmit timer to 0 You will observe
  89.  
  90. REcieve     Transmit
  91. ------      --------
  92. Packet 1
  93. packet 2       ACK1
  94. packet 3       ACK3
  95. packet 4       ACK4
  96. and so on.
  97. And the recieve rate will approach that of the serial line.
  98.  
  99. I suspect (this is really wild speculation) that things work fine for
  100. many people because the re-transmit timer is smaller than the total
  101. time to send a window's worth of data.  The sequence may look like this
  102.  
  103. REcieve     Transmit
  104. ------      --------
  105. Packet 1
  106. Packet 2        ACK1
  107. Packet 3        *** ACK2 is not sent
  108. Packet 4        *** ACK3 is not sent
  109. Packet 5        *** ACK4 is not sent
  110. Packet 6        ACK5 is sent because the re-transmit timer has expired
  111.                 and a Packet was recieved, stimulating MacTcp to send
  112.                 a current ACKnowledgement, and versaterm Slip lets it 
  113.                 through!
  114. Packet 7        *** ACK6 is not sent
  115. and so on.
  116.  
  117. Now for more knowledgeable TCP people, Yes, Sequence number and ACK fields
  118. are byte quantities and go up by much more than one at a time.  Also I may
  119. be using slightly incorrect terminology when refferring to Sequence and ACK
  120. fields.
  121.  
  122. I found this out doing a line anaylzer trace of the 
  123. serial line.  I called Synergy software, and they talked to the author, 
  124. whose response was
  125.  
  126. "the re-transmit problem  will be fixed in Future Versions of MacTcp.  
  127. Just turn off the re-transmit timer if it is causing problems"
  128.  
  129. So that is what I do.  The recieve rate goes way up, although the transmit
  130. rate goes down (MacTcp is now sending duplicate data across the line).
  131. Since I do almost all receives, this works fine for me.
  132.  
  133. So If I am correct (I have strong evidence of the above in my config,
  134. but zero evidence anywhere else), Whether Versaterm Slip works well for
  135. you with the re-transmit timer depends on a complicated relationship of
  136. a) The transmit window of the sending device
  137. b) the MTU size
  138. c) The transmition rate
  139. d) the latencies involved because of compression time, modem latency, 
  140.    slip server delays and so on.
  141. e) the re-transmit timer in Versaterm Slip.
  142. f) Others??
  143.  
  144. ANOTHER POSSIBILITY.....
  145.  
  146. Now there is a second possible problem that I also ran into with
  147. similar symptoms.  
  148. Background:
  149. The Terminal server running SLIP must buffer
  150. as many packets as the sending device will send in one window.  This is
  151. because the sender on the LAN will assume network speeds and send
  152. the full window almost imediately.  If the Slip server 
  153. does not hold the entire window of data, and send it as possible on the
  154. line, then one or more packets will be lost and the sender will
  155. have to time out and re-send the data.  This results in the timeout you
  156. are noticing on the LED's.  
  157.  
  158. Now there are two things
  159. encouraging designers to set the buffer space small.  One is reduction
  160. in memory usage in the terminal server, and the other has to do with
  161. re-transmit problems.  If the sender on the Ethernet(or whatever lan)
  162. is re-transmitting too soon, then performance will actually be better
  163. if the SLIP server throws away most of those extra re-transmissions.
  164. A limited queue depth is one way to do this.  Another way to look at it
  165. is that data sitting in SLIP server memory is aging and becomes useless
  166. after too long.  Sending it then just uses up line bandwidth.
  167.  
  168. This is the reason that SLIP server implementations may only allow
  169. 4-8 packets to be buffered in their transmit queue.  This may not be 
  170. adequate.  The case I ran
  171. into is that the packet queue size was sufficient for the sending device,
  172. but overflowed whenever too many broadcast packets were recieved, or if
  173. a second TCP connection was started.  The solution was to 
  174. A) turn off Broadcast traffic on the SLIP line
  175. B) find out how to configure the SLIP server to hold more packets, 
  176. so there is no packet loss.  
  177.  
  178. If the TCP devices on the network are respecting Slow start(Sun's do), then
  179. things should work with a reasonable queue size.  I had to set my queue
  180. size to 16 packets, and I turned off broadcast packets since they have
  181. no utility on the Mac.   However, I was using a 3Com terminal server, not
  182. an Annex, so I have no idea what annex allows/supports.
  183.  
  184. Good Luck, it can Work!!!
  185.  
  186.  
  187. --
  188. -------------------------------------------------------------------------
  189. | Mark Isfeld   
  190. | Mark_Isfeld@3Com.com                     
  191. | 408-764-5167                        
  192.