home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9419 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  4.0 KB
  1. Xref: sparky comp.sys.sun.admin:9419 comp.sys.sun.hardware:6231 comp.unix.solaris:416
  2. Newsgroups: comp.sys.sun.admin,comp.sys.sun.hardware,comp.unix.solaris
  3. Path: sparky!uunet!mcsun!sun4nl!fwi.uva.nl!casper
  4. From: casper@fwi.uva.nl (Casper H.S. Dik)
  5. Subject: Re: SPARCclassic and SunOS 4.1.x
  6. Message-ID: <1992Dec14.175428.26161@fwi.uva.nl>
  7. Sender: news@fwi.uva.nl
  8. Nntp-Posting-Host: adam.fwi.uva.nl
  9. Organization: FWI, University of Amsterdam
  10. References: <Bz4D02.DD7@news.fai.com> <1992Dec14.071012.10498@zip.eecs.umich.edu> <1992Dec14.084639.18266@fwi.uva.nl> <Bz9446.AB6@cs.columbia.edu>
  11. Date: Mon, 14 Dec 1992 17:54:28 GMT
  12. Lines: 66
  13.  
  14. carson@cs.columbia.edu (Carson A. Gaspar) writes:
  15.  
  16. >I, personally, have nothing against the SVR4 API.  It's the
  17. >_implementation_ that is horrible.  The code as shipped from USL is
  18. >horrible (unless SVR4.2 fixed things) and many vendors actually ship
  19. >it without re-writing so it works properly and performs decently.
  20.  
  21. We have the SVR4.2 code and yes, it doesn't look nice. We never ran
  22. it on any hardware, so I can't judge the performance.
  23.  
  24. >Now, as far as I know, Sun has fixed the known bugs in USL's code, and
  25. >has greatly improved performance. _HOWEVER_, the numbers still show
  26. >that 4.1.3 is _much_ faster than Solaris 2.1.  Now, if you have a sun
  27. >multi-processor machine, Solaris 2.1 may be faster as it _finally_
  28. >implements an SMP kernal.  Of course, solbourne has an SMP kernal
  29. >based on 4.1.3 that screams, but they don't sell their OS for
  30. >non-solbourne hardware (too bad).
  31.  
  32. I don't know where you get the ``_much_ faster than''. The
  33. press releases tell us there is a difference in the areas were
  34. performance was affected most of about -10%. Some performance was actually
  35. improvement over 4.x. I've just started to play with Solaris 2.1
  36. (much faster than 2.0) on an SLC, and I don't feel that it is
  37. slower than 4.x. I'm also impressed by the ease of installation and
  38. the new features that make things easier to handle. I'm just not
  39. sure whether all these new features will scale well in an large
  40. installation.
  41.  
  42. >The real question is - when is Sun going to stop slowing down the O/S
  43. >with each major release (I know several people who have upgraded to
  44. >SunOS 3.x for performance improvements - they find it unfortunate that
  45. >they can't run it on all their Sun hardware).
  46.  
  47. My feeling is that they just did. If we disregard 2.0 (which was
  48. a test release, nothing more), we can say that 2.x isn't much slower
  49. than 4.x, especially considering that they are still tuning Solaris 2.x.
  50. What bothers me most is the always increasing memory use. You could
  51. run 3.x in 4MB, you needed 8MB to get 4.x going, now you need 12MB to
  52. get Solaris 2.x going. (The memory sizes are the absolute minimum,
  53. to be fair to Solaris 2.x, it should be noted that that memory requirement
  54. is because the installation is done swapless. Need feature, being able
  55. to remove all disk-based swapspace)
  56.  
  57. >                        Sun (and, to be fair,
  58. >most O/S vendors) keep shipping systems that are more and more
  59. >bloated.  There are several alternative kernal architechtures that
  60. >have been implemented, tested, and proven to outpreform monolithic
  61. >kernals (Henry Massalin's Synthesis spawns threads about an order of
  62. >magnitude faster than SunOS calls functions).  It's well past time
  63. >that the industry took advantage of the new technology.  Mach is a
  64. >nice first round, and proof that you can maintain the familiar API(or
  65. >APIs!) while greatly improving performance.  While NeXTStep has not
  66. >yet moved to the Mach microkernal (due to stability considerations),
  67. >it will be interesting to pit NeXTStep 486 against other vendors' SVR4
  68. >(including Solaris) on the same hardware and see what the numbers have
  69. >to say.
  70.  
  71. This would definitely interest me too. In a few months time we will be able
  72. to benchmark NeXTStep 486 vs Solaris 2.x/368 (or whatever they will call it)
  73. vs linux vs 368BSD vs BSDI vs the different SVR4s (Destiny/Dell etc) on
  74. exactly the same hardware. The numbers will tell us.
  75.  
  76. (I've changed the newsgroups headers a bit, this doesn't seem to belong in
  77. a misc.forsale.* group)
  78.  
  79. Casper
  80.