home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 237 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!miw
  3. From: miw@cc.uq.oz.au (Mark I. Williams)
  4. Subject: Re: Cell SIze
  5. Message-ID: <miw.711957276@cc.uq.oz.au>
  6. Sender: news@bunyip.cc.uq.oz.au (USENET News System)
  7. Organization: Prentice Centre, University of Queensland
  8. References: <1992Jul18.162524.22420@sics.se>
  9. Date: Fri, 24 Jul 1992 05:54:36 GMT
  10. Lines: 38
  11.  
  12. craig@sics.se (Craig Partridge) writes:
  13.  
  14. >>  In this experiment I suppose that the network managers would set the
  15. >>  cell size so that the smaller packets, about 50-80 bytes long, would
  16. >>  rarely fill onto cells.  Am I right?   What would be the actual cell size
  17. >>  selected assuming today's traffic?
  18.  
  19. >This is a fun question (even if somewhat hypothetical).
  20. [.......]
  21. >Note that if you were trying to compromise on these various tradeoffs,
  22. >you'd probably pick a size that balance interrupt costs and bandwidth.
  23. >My guess (based on what I've seen of predicted processor performance
  24. >and estimated packet sizes) is that you'd choose a size of about 1,000
  25. >bits (c. 128 bytes), which was one of the original proposals to CCITT.
  26.  
  27. Yes, but...but.... This analysis considers data traffic only! Remember
  28. that ATM will be expected to provide other services as well. With a cell
  29. payload of 128 bytes echo cancellation will be even more difficult than
  30. with 64 bytes. 
  31.  
  32. Consider also a telephone-quality voice channel: the data rate is 16
  33. kbps. If you have a cell size of 128 bytes, the "lumpiness" is
  34. introducing a delay of 62.5 milliseconds before the bits have travelled
  35. an inch. Add a bit of buffering to smooth out delay jitter (which is
  36. also somewhat dependent on the cell size) and it quickly becomes
  37. apparent that 128 octets is "A Power too Far". Of course you could
  38. simply only send 32 octets per cell when you had a long-distance
  39. call....:-)
  40.  
  41. My apologies if you *meant* only to consider data traffic.
  42.  
  43. cheers,
  44.  
  45. --
  46. Mark Williams         The University of Queensland       miw@cc.uq.edu.au
  47. +61 7 36 54012   (w)  Prentice Centre
  48. +61 7 36 54477  (fax) Qld 4072  Australia
  49. Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca
  50.