home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / cellrel / 425 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  2.9 KB
  1. Xref: sparky comp.dcom.cell-relay:425 comp.dcom.lans.fddi:575
  2. Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
  3. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!ames!sgi!rhyolite!vjs
  4. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  5. Subject: Re: >>>>Future of IP routers
  6. Message-ID: <p87dj5o@rhyolite.wpd.sgi.com>
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. References: <1992Aug28.164008.4015@sics.se> <p6dueak@rhyolite.wpd.sgi.com> <1992Aug30.194536.2545@amd.com>
  9. Date: Mon, 31 Aug 1992 01:24:53 GMT
  10. Lines: 49
  11.  
  12. In article <1992Aug30.194536.2545@amd.com>, shah@angelo.amd.com (Amit Shah) writes:
  13. > >
  14. > I have a slight disagreement with your statement that FDDI TTRT by itself
  15. > does not matter.  It depends on the type of traffic you put on the network.
  16. > If you are talking about bursting traffic in excess of 100 Mbps (such as
  17. > high-end imaging), with >2 stations on the ring then the
  18. > TTRT does matter (Lower TTRT will have lower throughput and buffer overflows).
  19. > 
  20. > However, if you are talking about normal traffic (burst rates not exceeding
  21. > 100 Mbps) then you are correct within a few percent points.
  22.  
  23.  
  24. I beg to differ, although I have few kind words for those who force
  25. customers to have stupidly tiny TTRT's instead of following .
  26.  
  27. In no case can an old-fashioned, non-Large-Window TCP/IP sender
  28. transmit more than 64KBytes without allowing the TCP receiver a chance
  29. to transmit at least one ACK.  In other words, the token must be
  30. released by the TCP transmitter at least once every 5.2 milliseconds.
  31. The obvious way to send TCP data in steady state is to arrange for one
  32. ACK per half of the TCP window, or one ACK every 32KB, or one token
  33. rotation every 2.6 milliseconds.
  34.  
  35. While the token is rotating, no data is being transmitted.  Therefore,
  36. if your ring latency is large, you might choose to transmit 64KB and
  37. then wait for one (burst of) ACK(s) every 5.2 ms, in the hope that your
  38. transmitter's latency in resuming TCP transmissions is less than the
  39. cost of the dead time.  If your systems are fast, this is a reasonable
  40. hope, since ring latencies can be up to 1.67 ms.  If you waste 1 ms on
  41. token rotations every 2.6 ms, you are not going to get close to the
  42. speed of light, which is around 97Mbit/sec.
  43.  
  44. Please notice that 2.6 ms is far lower than the minimum universally
  45. legal TTRT, and even 5.2 ms is not significantly larger than the silly
  46. and very wrong (in my opinion) TTRT imposed by default by one large
  47. vendor.
  48.  
  49. I agree that a small TTRT with a large or even modest ring latencies
  50. have bad effects on massive UDP output rates.  However, I do not know
  51. of a realistic application for sending megabytes of UDP data.  That
  52. `ttcp -u` gives such UDP numbers does not by itself make them
  53. interesting.
  54.  
  55. These assertions are not based on readings of standards.  I haven't
  56. played with 1 ms ring latencies, but I have spent time with the other
  57. circumstances I have implicitly described.
  58.  
  59.  
  60. Vernon Schryver,  vjs@sgi.com
  61.