home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / os2 / advocacy / 10952 < prev    next >
Encoding:
Text File  |  1992-12-26  |  9.6 KB  |  268 lines

  1. Newsgroups: comp.os.os2.advocacy
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!rsrodger
  3. From: rsrodger@wam.umd.edu (Yamanari)
  4. Subject: Re: OS/2 bigot meets NT....
  5. Message-ID: <1992Dec26.152341.22670@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac1.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <1992Dec25.180324.15834@donau.et.tudelft.nl> <1992Dec25.202426.19125@wam.umd.edu> <1992Dec26.112618.22243@donau.et.tudelft.nl>
  10. Date: Sat, 26 Dec 1992 15:23:41 GMT
  11. Lines: 255
  12.  
  13. In article <1992Dec26.112618.22243@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
  14. >rsrodger@wam.umd.edu (Yamanari) writes:
  15. >
  16. >>In article <1992Dec25.180324.15834@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
  17. >>>rsrodger@wam.umd.edu (Yamanari) writes:
  18. >>>
  19. >>i    [2 pages of same stuff deleted]
  20. >
  21. >>>>    Install OS/2 2.0 on a 16 meg system.  Adjust the cache sizes to 
  22. >>>>    what is proper for a 16 megger (read: OS/2 isn't bright about 
  23. >>>>    this)--you know, HPFS and the whole deal.
  24. >>>
  25. >>>Is it supposed to change your settings then whenever you change
  26. >>>your amount of memory? 
  27. >
  28. >>    No, but the normal cache setting for OS/2 is
  29. >>    a poor choice for anyone with 8 megs or more.  
  30. >
  31. >>    We can assume that either NT is the same (and the original
  32. >>    user, with 16 megs, has adjusted it) or that it auto-adjusts.
  33. >>    If the later, then my argument is eliminated. 
  34. >
  35. >
  36. >>>On what bases should it do that? Is there
  37. >>>some heuristic technique that allows it to choose a proper setting
  38. >>>by itself? 
  39. >
  40. >
  41. >>    I do not know whether it does or not.  But I am *certain* 
  42. >>    that if it does not, the previous owner would have fixed it
  43. >>    for his 16 meg system.
  44. >
  45. >You lost me here. What do you mean you do not know? 
  46.  
  47.  
  48.     We are discussing NT.  We are discussing NT that has been
  49.     in use on a 16 meg system that was moved *directly*--
  50.     that is, sans modification/configuration changes
  51.     toa system with 1/2 the memory--but not just 1/2 the memory,
  52.     but to a system with the *minimum allowable memory*.
  53.  
  54.     My argument is that it is safe to assume that the previous
  55.     owner fiddled with it to boost performance on his 16 meg
  56.     system.  This would tend to mean boosting the cache sizes,
  57.     using certain things that you couldn't before 
  58.     ram drives, NTFS ~= HPFS, etc. etc.) which will
  59.     do bad things to even OS/2--now put those same problems
  60.     on a beta system that's already overtaxing the VM
  61.     code and we're suprised that it's crashing?  
  62.  
  63.     The problem is lack of information--all that we do know is
  64.     that it was on a 16 meg machine before, and on an
  65.     8 meg now.  I have *used* the beta for a good period of
  66.     time and had nothing like the number of crashes that he's
  67.     reporting--*obviously* something is wrong with his configuration,
  68.     and posting this type of thing as representitive of NT (or anything)
  69.     is pure FUD.
  70.  
  71.  
  72. >OS/2 does
  73. >not change settings dynamically, I thought it was you who
  74. >said that. 
  75.  
  76.  
  77.     We were discussing NT and possible reasons for the problem.
  78.     If NT does adjust settings automatically, then the cache sizes
  79.     (, etc) would be adjusted and that was not a possible 
  80.     solution to the problem.  If it DOES NOT, then there is a possible
  81.     cause.  Other causes--which could not be adjusted for automatically
  82.     might also come into play--NTFS, ram drives, whatever.  (Although,
  83.     I do not know if MS warns users off low memory+NTFS combinations
  84.     in the same way IBM does [hpfs]...)
  85.  
  86.  
  87.  
  88. >I was talking about systems in general, changing
  89. >settings when they detect changes to the hardware. There is
  90. >no previous owner involved.
  91.  
  92.  
  93.     YES THERE IS.  The version of NT that he is reviewing is coming 
  94.     unchanged from a 16 meg system to his own 8 meg system 
  95.     (otherwise "mostly identical").  If you were using OS/2 on a 
  96.     8 meg system--wouldn't you do certain things--like use
  97.     HPFS and a larger cache?  Now, suppose you pulled 4 megs of
  98.     memory out--how stable do you think that system would be?
  99.  
  100.     <I've done it, and the best answer is "not very, but so slow it
  101.     doesn't really matter">
  102.  
  103.  
  104. >>>Would you want a system to change the parameters you
  105. >>>have carefully selected? 
  106. >>    Such a system would not have "parameters carefully selected"
  107. >
  108. >Huh, again? Having had to much of your christmas meal? :-)
  109. >I was trying to say that I do not want the system to change
  110. >my carefully selected parameters without consulting me.
  111.  
  112.     Like I said--a system that auto-set parameters (neither 
  113.     OS/2 or NT is such a system as far as I know[for NT--we all
  114.     know OS/2 isn't]) would not have "carefully selected 
  115.     parameters" because they would have been selected and set
  116.     by the system, not the user.
  117.  
  118.  
  119.  
  120. >I should specify, I do want it to adjust to changes, like
  121. >more or less par/ser ports, changes in interrupt lines etc.,
  122.  
  123.  
  124.     Agreed--but this is also a PC thing.  On an Amiga or a Mac
  125.     you don't have to fiddle with rediculous things like CMOS
  126.     settings for this stuff.
  127.  
  128.  
  129.  
  130. >but not the cache size or timeslices, priority etc. I most likely
  131.  
  132.                     ^^^ Sure about that?
  133.  
  134.  
  135. >had good reason to choose them, and I would like to continue
  136. >to have them choosen with proper motives, not some systems
  137. >programmers best guess.
  138.  
  139.  
  140.     Two different approaches, two different tastes.  
  141.     I, personally, don't see any real-world difference
  142.     between the two--one is more convienient, but probably
  143.     get's nearly 90% as good, settings wise, as the other
  144.     less convenient one--but that one opens the doors to
  145.     users totally screwing up their settings.
  146.  
  147.  
  148.  
  149. >>>If you mean it could make a suggestion
  150. >>>when it finds a change, I agree, but no more than that.
  151.  
  152. >>You're thinking like a dos user.  It is not a bad idea to have
  153. >>the system auto-adjust and *allow* the user to fix it when you're
  154. >>talking about something that's suposed to be user friendly.  
  155.  
  156. >As I said above, I agree to some point, but also the user should
  157. >be notified of the change, so he isn't kept in the dark about possible
  158. >causes for changed performance. This too is user friendlyness.
  159.  
  160.  
  161.     I disagree--who wants a message saying "For performance 
  162.     reasons, the DosWhooZiMutz parameter is being set to 
  163.     1024.  Proceed?"--in an OS targeted at real users?  If anything,
  164.     OS/2 would probably have better market penetration if it 
  165.     didn't force users to fiddle with settings to get their programs
  166.     to work--or work with any kind of reasonable performance.  
  167.     While you and I would like to disable this feature, an 
  168.     intelligent auto-settings program should be standard and
  169.     default.  
  170.  
  171.     Most users can't deal with setting up DOS and Windows--
  172.     these days, they shouldn't have to fiddle to get it to work.
  173.  
  174.     <Hint:  "Why The Mac Succeeded Even If It Isn't Perfect">
  175.  
  176.  
  177.  
  178. >>>>    Take this system, back it up, and put it on a 6 megger.  The 
  179. >>>>    system will run so poorly and be so unstable that you'd think
  180. >>>>    OS/2 was written by a bunch of monkeys with typewriters.
  181. >>>
  182. >>>Let me see now. Having OS/2 installed on a 6 megger and then
  183. >>>adjusting the memory settings of the 16 meg system would
  184. >>>result in the exact same setup right?
  185. >
  186. >>    ...only if you then took *that* setup (the one optimized for
  187. >>    16) and moved it *back* to a 6 megger w/o *any* change.
  188. >
  189. >No, we, you and I, were talking about optimising cache settings.
  190. >So changing those would result in the same setup.
  191.  
  192.  
  193.     *What*? 
  194.  
  195.  
  196. >>>In other words, OS/2 becomes instable if you change your
  197. >>>cache settings? 
  198.  
  199. >>    OS/2 behaves funny when you have low memory and are using
  200. >>    the HPFS.  IBM tech support themselves will recommend 
  201. >>    not using HPFS if you have less than 8 megs and I have
  202. >>    been told this is not only because it slows the system to
  203. >>    a crawl, but because a system with the swap file on an 
  204. >>    HPFS partition with 6 megs or less will have problems
  205. >>    (I was told this two seperate times by two seperate IBM techs).
  206. >
  207. >>    I think there's a comment to this effect in the faq, too.
  208. >
  209. >
  210. >>>I find that highly unlikely, and if indeed this
  211. >>>would be the case, it shows poor programming.
  212. >
  213. >>    You said it, not me.
  214. >
  215. >You can say it too if it is true. I'd kick myself if I ever did such
  216. >a thing, so why not tell someone else off. It should be of very high
  217. >priority to get this right, after all, it is one of the main
  218. >mechanisms in a system.
  219.  
  220.  
  221.     Which makes it interesting, doesn't it, that OS/2 doesn't
  222.     auto-adjust these things.  Actually, *I* prefer it that
  223.     way, but I think it's hurting OS/2.  Install OS/2 on 
  224.     a 16 meg system--you'd think that it would be configured
  225.     for optimal performance.  Well... <no>
  226.  
  227.  
  228. >>> However,
  229. >>>I see no reason for it to be so, since, the same effect would be
  230. >>>gotten when the system becomes low on memory for other reasons,
  231. >>>like too many jobs. 
  232. >>>poorly) but it does not affect stability. Stability is not a
  233. >>>function of memory available, so the system is most likely to
  234.  
  235. >>    Obviously, you never used the 2.0 beta, which became
  236.  
  237. >True.
  238.  
  239. >>    about 90% less stable when it started to use virtual memory.
  240. >>    This was before they plugged most of the big holes 
  241. >>    in VM.  VM is not something simple, it is just more room
  242.  
  243. >It is to someone who knows his bussiness.
  244.  
  245.  
  246.     Well, then IBM must not have known it very well in the pre-LA
  247.     2.0 beta.
  248.  
  249.  
  250. >>    for bugs to hide in.  So what this guy is doing is roughly
  251. >>    equiv. to running the OS/2 beta in 4 megs--with it 
  252. >>    configured for 8--so *of course* it's slow and unstable.
  253. >
  254. >>>remain as stable or unstable as it was before the memory change.
  255. >
  256. >
  257. >    Nope.  OS/2 had more than it's share of VM induced
  258. >>    instability (still does, probably--might explain some
  259. >>    of those funny "impossible to explain" crashes, but it seems
  260. >>    pretty solid since the SP).
  261.  
  262.  
  263. -- 
  264.        "If you can't eat sand, why the hell are you living in a desert?"
  265.  
  266.      Equality is a delusion, suffering is a fairy tale and God is a fantasy.
  267.        Blaming society for inequality is like blaming the sky for rain.
  268.