home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / novell / 11962 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  2.4 KB
  1. Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!scsing.switch.ch!news.univie.ac.at!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!harvey
  2. From: harvey@indyvax.iupui.edu
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: Can Novell support 75+ workstations?
  5. Message-ID: <1993Jan26.163048.271@indyvax.iupui.edu>
  6. Date: 26 Jan 93 16:30:48 -0500
  7. References: <728078512.AA00323@f262.n620.z3.fidonet.org>
  8. Organization: Indiana University-Purdue University at Indianapolis
  9. Lines: 40
  10.  
  11. In article <728078512.AA00323@f262.n620.z3.fidonet.org>, tp923021@jarrah.canberra.edu.au (ben elliston) writes:
  12. >  > Considering that the specified limit for a thin
  13. >  > segement is 185 meters,
  14. >  > I doubt that any of us want to. We've got a total of
  15. >  > about 4,000 feet of
  16. >  > thin coax bridged via NetWare servers and dedicated
  17. >  > bridges (PCBridge),
  18. >  > and I've strained mightily to keep each segement under
  19. >  > the limit. Oddly
  20. >  > enough, my network is quite reliable. How's yours?
  21. >
  22. > Alright .. it's quite fast (90% of top speed), but you guessed it, we get drop outs (lost workstation connections) about once a week. :-)
  23. >
  24. >  > (Oh, BTW; I've heard of a thin LAN that had over 1.2KM
  25. >  > of cable, but for
  26. >  > *some* reason, performance wasn't real good....)
  27. >
  28. > Yeah, funny that!
  29. >
  30. > Cheers, Ben
  31.  
  32. Stretching network construction guidelines is penny-wise and pound-foolish
  33. IMHO.  Individual components are assumed to be manufactured to perform within
  34. a specified range of tolerances.  A certain set of rules (hopefully simple)
  35. is assumed to hold for how the system as a whole is put together.  Given these
  36. assumptions, certain useful statements can then be made about the performance
  37. of the resulting system.  The idea is that the end user is not required to
  38. perform or understand the analysis of the entire system, but only to use
  39. standardized components and follow some basic rules.  Many engineered systems
  40. are designed this way, not just LANs.
  41.  
  42. Basically, the end user buys a cookbook approach to setting up the LAN in
  43. return for a very small tradeoff in hardware costs.
  44.  
  45. Sure, in a particular set of circumstances you might be able to "get away"
  46. with something, but if you add another station or replace some equipment and
  47. and it blows up in your face, you really have no one but yourself to blame.
  48. --
  49. James Harvey    IUPUI/OIT Technical Support/VMS & Networks
  50. harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
  51.