home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 742 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.2 KB
  1. Path: sparky!uunet!hela.iti.org!usc!isi.edu!finn
  2. From: finn@isi.edu (Greg Finn)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Re: Computers dont like ATM?
  5. Message-ID: <22909@venera.isi.edu>
  6. Date: 18 Nov 92 19:38:06 GMT
  7. References: <1992Nov18.025754.14749@trl.oz.au>
  8. Sender: news@isi.edu
  9. Reply-To: finn@dalek.isi.edu (Greg Finn)
  10. Organization: USC-Information Sciences Institute
  11. Lines: 54
  12.  
  13. In article <1992Nov18.025754.14749@trl.oz.au> you write:
  14. >This morning I heard a talk by Dr Paul Green from IBM Research ...
  15. >More or less in passing, he mentioned that 53 byte cells are too small
  16. >for computers (or words to that effect).  His claim was that small
  17. >packets ... make a lot of unnecessary work for the computer that has to
  18. >receive them, since it has to process a header every 53 bytes ...
  19. >He also seemed to be suggesting that this storage and retrieval process
  20. >could become a bottleneck (at 100s of Mbit/s?) because of the limitations 
  21. >of memory bandwidth.
  22.  
  23.     Very true.  I co-developed a multi-gigabit LAN.  If a
  24. store-and-forward (or retrieve) operation is to occur without reducing
  25. the channel bandwidth, it requires memory that operates at twice the
  26. channel rate.  Our simplex channels operate nominally at 500 Mb/s and
  27. require 33 MHz memory.  Using CMOS it is very difficult to create bulk
  28. memory that operates at 33 MHz, let alone 66 MHz.
  29.  
  30.     Packet storage within a switch should be avoided at high
  31. channel rates if practical and can be accomplished with cut-through
  32. routing.  This issue has nothing whatsoever to do with fixed versus
  33. variable-length packets.  Avoiding the need for storage within a
  34. switch is even more important in the all-optical domain.
  35.  
  36. >He was advocating variable length packets (an idea
  37. >called PTM - packet transfer mode - that IBM has proposed), because it
  38. >puts the complexity in the switch rather than in the receiving
  39. >terminal. 
  40.  
  41.     I know nothing about the desirability of PTM in telco
  42. switching.  I can say something about LANs.  PTM allows one to design
  43. LANs that are exceedingly fast and that have tiny host interfaces that
  44. require no fragmentation/reassembly hardware.  PTM allows one to make
  45. LAN switches as simple as ATM-based LAN switches if the right routing
  46. technology is chosen.  Source routing and a variant of cut-through now
  47. used in multicomputers provided us a datagram routing decision of
  48. about 30ns per hop and yields a 10 Gb/s 32x32 crossbar that is smaller
  49. that an 8.5x11 inch sheet of paper.
  50.  
  51. >From this, his conclusion was (I think) that ATM is good for switching
  52. >voice traffic, but not so good for computer networks.  This seems to go 
  53. >against what's actually happening, with people building ATM LANs while 
  54. >telcos hang back, not sure if ATM is the right way to go.
  55.  
  56.     ATM is politically very popular.  Arguments that ATM brings
  57. about end-to-end compatibility do not impress me.  Most LAN traffic
  58. stays within the LAN.  Forcing LANs to comply with WAN data-link
  59. standards is putting the cart before the horse.  I have great
  60. reservations about what ATM costs us in LANs.  When ATM-based LAN
  61. performance exceeds PTM-based LAN performance/cost, ATM proponents
  62. will have a much better argument than they now have.  Frankly, I don't
  63. forsee that happening in the electrical domain.
  64. --
  65. Gregory Finn    (310) 822-1511
  66. Information Sciences Institute, Marina Del Rey, CA 90292
  67.