home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 12030 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  5.0 KB

  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!bhamcs!axs
  2. From: axs@cs.bham.ac.uk (Aaron Sloman)
  3. Newsgroups: comp.arch
  4. Subject: Re: IBM AS/400 is the world's slowest.. (actually multiuser systems)
  5. Message-ID: <C086Et.Fx7@cs.bham.ac.uk>
  6. Date: 2 Jan 93 11:54:28 GMT
  7. References: <1992Dec21.141558.18626@rchland.ibm.com> <id.HD1W.X03@ferranti.com> <1992Dec26.003022.25532@bilver.uucp> <id.TX9W.FC3@ferranti.com> <1993Jan1.102554.28575@metapro.DIALix.oz.au> <C07DK0.E7t@cs.bham.ac.uk> <1i30e3INNksu@cbl.umd.edu>
  8. Sender: news@cs.bham.ac.uk
  9. Organization: School of Computer Science, University of Birmingham, UK
  10. Lines: 102
  11. Nntp-Posting-Host: emotsun
  12.  
  13. mike@starburst.umd.edu (Michael F. Santangelo) writes:
  14.  
  15. > Date: 2 Jan 93 02:59:15 GMT
  16. > Organization: University of Maryland, Chesapeake Biological Laboratory
  17. >
  18. > axs@cs.bham.ac.uk (Aaron Sloman) writes:
  19. >
  20. > >This discussion omits another option: instead of character-cell
  21. > >terminals you can use X terminals connected to a powerful,
  22. > >expandable, shared compute/file server. For many kinds of users this
  23. > >combination provides most of the benefits of a workstation on each
  24. > >user's desk but at a lower cost per user (including memory costs,
  25. > >system management costs, etc.). ...
  26.  
  27.     [stuff omitted]
  28.  
  29. > X-terminals are not themselves the cure-all either.
  30.  
  31. I agree, and tried to indicate this when I wrote
  32. | > .....(Obviously some kinds of users
  33. | >should not be on a shared machine, or should not have their screens
  34. | >driven over a network ....
  35.  
  36. > .....Like diskless
  37. > workstations they rely on decent networking as they produce quite a lot
  38. > of network traffic.
  39.  
  40. For certain classes of users, e.g. people doing quite a lot of
  41. ----------------------------
  42. editing, starting and stopping processes (compilers, editors,
  43. linkers, various applications programs, etc.) a diskless workstation
  44. will cause a lot *more* network traffic (reading in large executables
  45. from the server, swapping, reading and writing files) than an X
  46. terminal (for which the *only* network traffic is keyboard and mouse
  47. signals and data to update the screen). (This can also be true of
  48. workstations with small local disks, linked to a shared file server:
  49. all they save is swapping and paging over the network. But they
  50. have a bigger administrative cost than X terminals.)
  51.  
  52. If the interaction is mostly character based with occasional vector
  53. graphics or bitmap displays, the network traffic per X terminal user
  54. need not be high, though it will be higher than for a pure character
  55. terminal. Of course if you have enough users on the same network any
  56. class of terminal can generate too much network traffic.
  57.  
  58. >..Ethernet with its CSMA/CD architecture and 10Mb/sec
  59. > bandwidth can be brought to its knees with these devices when the usage
  60. > is moderate or more (depending as well on the # of stations).
  61.  
  62. Yes. But what I am saying is that (for most(?) sorts of users) the
  63. amounts of network traffic generated can approximately be ordered
  64. thus:
  65.  
  66.     workstations >  X terminals > character terminals
  67.  
  68. What is not always appreciated is that even if the workstations have
  69. local disks they can still generate more net traffic than X
  70. terminals if all users share a common file store, which is often
  71. essential e.g. because local disks are small.
  72.  
  73. > ....At
  74. > least with multiuser systems the terminal equipment was all character
  75. > based using I/O controllers that were often distributed (multipoint)
  76. > for the big guys or point-to-point between the terminal and the multiuser
  77. > computer systems.
  78.  
  79. And now with X terminals, faster communications, more powerful and
  80. *expandable* servers, etc. we can go back to that model but with far
  81. higher functionality for the same overall cost. The dominant dogma
  82. nowadays seems to be that "distributed processing is most
  83. beautiful". All I am trying to do is undermine that as an
  84. unqualified generalisation. Each pattern of use has to be analysed
  85. carefully.
  86.  
  87. > The world of OLTP is a far different than academic/college environments.
  88. > I've been in both.
  89.  
  90. I agree that different environments have different requirements. I
  91. suspect that many commercial/industrial/administrative environments
  92. could benefit as much from the server + X terminal architecture as
  93. academic environments. (And of course not all academics are best
  94. suited by this, depending on what they are doing.)
  95.  
  96. > There is no one-solution-fits-all.  The best approach is to use the right
  97. > solution and implement a very supportive underlying networking
  98. > infrastructure.  Some of the older connectivity ideas still have their
  99. > place and are more suited to the job than some of the more modern ones.
  100.  
  101.  
  102. We seem to be in complete agreement!
  103.  
  104. > Michael F. Santangelo                 + Internet: mike@cbl.umd.edu      [work]
  105. > Computer & Network Systems Head       +           mike@kavishar.umd.edu [home]
  106. > Univ MD: CEES / CBL (Solomons Island) + BITNET:   MIKE@UMUC  [fwd to mike@cbl]
  107.  
  108. Aaron
  109. ---
  110. -- 
  111. Aaron Sloman, School of Computer Science,
  112. The University of Birmingham, B15 2TT, England
  113. EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
  114. Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281
  115.