home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 286 < prev    next >
Encoding:
Text File  |  1992-07-30  |  3.8 KB  |  88 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!mcsun!sun4nl!research.ptt.nl!walvdrk
  3. From: walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295)
  4. Subject: Re: Curious attitude ...
  5. Message-ID: <1992Jul30.184556.1@research.ptt.nl>
  6. Sender: usenet@spider.research.ptt.nl (USEnet News)
  7. Nntp-Posting-Host: dnlts0
  8. Organization: PTT Research, The Netherlands
  9. References: <12387@pinard> <22041@venera.isi.edu> <1992Jul29.164110.1@research.ptt.nl> <nu696eo@rhyolite.wpd.sgi.com>
  10. Date: Thu, 30 Jul 1992 17:45:56 GMT
  11. Lines: 75
  12.  
  13. In article <nu696eo@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon
  14. Schryver) writes: 
  15.  
  16. >> In article <22062@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:
  17. >>...
  18. >> >     No.  Multicast is NOT broadcasting.  A routing tree is
  19. >> > constructed so that the traffic flows according to what is ideally a
  20. >> > minimum-cost spanning tree.  Hardly broadcast I think.
  21.  
  22. >> I agree. The essence is that there's hardly any real time contraints when 
  23. >> doing none-interactive multicast.
  24.  
  25. > Wasn't the IETF multicast "interactive"?
  26.  
  27. I don't have any idea what IETF is. A group of people looking at a presentation
  28. on a videoscreen is not my understanding of "interactive". 
  29.  
  30.  
  31. > If you don't have some real time constraints, pictures get objectionably
  32. > jerky and voice is hard to understand.
  33.  
  34. What I meant to say is that if the information (picture, voice) is only going 
  35. into a single direction (from performer to audience) there's no problem to 
  36. smooth the variances in the delay. So no jerky pictures or 
  37. difficult-to-understand voice. For such an application I don't mind a total
  38. delay of (say) several seconds. 
  39.  
  40. If the audience is supposed to talk back ("interaction") I _do_ mind about the 
  41. delay.
  42.  
  43.  
  44. > 50 milliseconds is not at all hard to hit on typical ether-internets,
  45. > with workstations acting as routers.  (I know a little of such an
  46. > internet with a hundred or so ethernets, some FDDI and TR and a few
  47. > thousand workstations, and a little more about the hardware and
  48. > software of those workstations.)  Sometimes round trips get worse than
  49. > 50 msec, but then I've noticed my telephone tends to not work very well
  50. > shortly before the building is rattled by thunder.
  51.  
  52. Hmm, that's interesting information. Though not at all in line with what I
  53. experience (as a user) from the network here. But a major network-overhaul is 
  54. due for this weekend ...
  55.  
  56. But, what determines the performance (sustainable througput & delay) in such a
  57. network? My ignorant guess is, it's not the number of workstations but the
  58. amount of data these workstation produce, the attainable througput of (such a
  59. workstation-based) router and the number of routers that have to be passed. 
  60.  
  61. With all respect for data-people in general, for me it's a "small" network.
  62. Doing similar things in a world-wide network might make some difference.
  63.  
  64.  
  65. > Do you guys think that all of the "multi-media" people are without a
  66. > clue or a hope?  (I think many lack one or the other, but few lack
  67. > both.)
  68. > 
  69. > I'm trying to politely suggest that you telephony guys should get out
  70. > more.  See other parts of the world.  Good data networking people
  71. > generally know they don't know about telephony, but it is strange the
  72. > obverse does not seem to apply.  (I won't claim in public to be good,
  73. > but I will claim to not know too much about telephones.)
  74.  
  75. This looks (to me) as a flame against "you guys". Did "we" say anything wrong?
  76. Then "I" apologize. I never suggested (at least I didn't mean to suggest) there
  77. would be no hope for the world without ATM (or "telephony guys" for that
  78. matter). 
  79.  
  80.  
  81. Regards, <kees>
  82.  
  83. Kees  van der Wal               e-mail: J.C.vanderWal@research.ptt.nl
  84. ----------------------------------------------------------------------------
  85. PTT Research Neher Laboratories                      Room: E130
  86. Sint Paulusstraat 4                     Fax: +31 70 3326477
  87. 2264 XZ  Leidschendam  The Netherlands               Phone: +31 70 3326295
  88.