NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/os2/advocacy/10957

Text File | 1992-12-26 | 11.1 KB | 292 lines

Newsgroups: comp.os.os2.advocacy
Path: sparky!uunet!mcsun!sun4nl!dutrun!donau!dutecaj.et.tudelft.nl!linstee
From: [e-mail] (Erik van Linstee)
Subject: Re: OS/2 bigot meets NT....
Message-ID: <[e-mail]>
Sender: [e-mail] (UseNet News System)
Nntp-Posting-Host: dutecaj.et.tudelft.nl
Organization: Delft University of Technology, Dept. of Electrical Engineering
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 26 Dec 1992 18:01:15 GMT
Lines: 279

[e-mail] (Yamanari) writes:

>In article <[e-mail]> [e-mail] (Erik van Linstee) writes:
>>[e-mail] (Yamanari) writes:
>>
>>>In article <[e-mail]> [e-mail] (Erik van Linstee) writes:
>>>>[e-mail] (Yamanari) writes:
>>>>
>>>i    [2 pages of same stuff deleted]
>>
>>>>>    Install OS/2 2.0 on a 16 meg system.  Adjust the cache sizes to
>>>>>    what is proper for a 16 megger (read: OS/2 isn't bright about
>>>>>    this)--you know, HPFS and the whole deal.
>>>>
>>>>Is it supposed to change your settings then whenever you change
>>>>your amount of memory?
>>
>>>    No, but the normal cache setting for OS/2 is
>>>    a poor choice for anyone with 8 megs or more.
>>
>>>    We can assume that either NT is the same (and the original
>>>    user, with 16 megs, has adjusted it) or that it auto-adjusts.
>>>    If the later, then my argument is eliminated.
>>
>>
>>>>On what bases should it do that? Is there
>>>>some heuristic technique that allows it to choose a proper setting
>>>>by itself?
>>
>>
>>>    I do not know whether it does or not.  But I am *certain*
>>>    that if it does not, the previous owner would have fixed it
>>>    for his 16 meg system.
>>
>>You lost me here. What do you mean you do not know?


>    We are discussing NT.  We are discussing NT that has been
>    in use on a 16 meg system that was moved *directly*--
>    that is, sans modification/configuration changes
>    toa system with 1/2 the memory--but not just 1/2 the memory,
>    but to a system with the *minimum allowable memory*.

>    My argument is that it is safe to assume that the previous
>    owner fiddled with it to boost performance on his 16 meg
>    system.  This would tend to mean boosting the cache sizes,
>    using certain things that you couldn't before
>    ram drives, NTFS ~= HPFS, etc. etc.) which will
>    do bad things to even OS/2--now put those same problems
>    on a beta system that's already overtaxing the VM
>    code and we're suprised that it's crashing?

>    The problem is lack of information--all that we do know is
>    that it was on a 16 meg machine before, and on an
>    8 meg now.  I have *used* the beta for a good period of
>    time and had nothing like the number of crashes that he's
>    reporting--*obviously* something is wrong with his configuration,
>    and posting this type of thing as representitive of NT (or anything)
>    is pure FUD.

As it turns out, the NT beta was installed on an 8Meg system
and then moved to the other 8Meg system. As Steve already
stated. The 8Meg was added after the move, so I think this makes
previous posts about unfair comparisons obsolete.

>>OS/2 does
>>not change settings dynamically, I thought it was you who
>>said that.


>    We were discussing NT and possible reasons for the problem.
>    If NT does adjust settings automatically, then the cache sizes
>    (, etc) would be adjusted and that was not a possible
>    solution to the problem.  If it DOES NOT, then there is a possible
>    cause.  Other causes--which could not be adjusted for automatically
>    might also come into play--NTFS, ram drives, whatever.  (Although,
>    I do not know if MS warns users off low memory+NTFS combinations
>    in the same way IBM does [hpfs]...)

Then I should clarify. My original reaction was to you saying
OS/2 isn't to bright about adjusting system settings. Reread it
with that knowledge and you'll understand my confusement with
your reactions.


>>I was talking about systems in general, changing
>>settings when they detect changes to the hardware. There is
>>no previous owner involved.


>    YES THERE IS.  The version of NT that he is reviewing is coming

No there isn't (see above). I was not reacting to this discussion
about NT, but to systems changing there settings for whatever
reason.

>    unchanged from a 16 meg system to his own 8 meg system
>    (otherwise "mostly identical").  If you were using OS/2 on a
>    8 meg system--wouldn't you do certain things--like use
>    HPFS and a larger cache?  Now, suppose you pulled 4 megs of
>    memory out--how stable do you think that system would be?

>    <I've done it, and the best answer is "not very, but so slow it
>    doesn't really matter">


>>>>Would you want a system to change the parameters you
>>>>have carefully selected?
>>>    Such a system would not have "parameters carefully selected"
>>
>>Huh, again? Having had to much of your christmas meal? :-)
>>I was trying to say that I do not want the system to change
>>my carefully selected parameters without consulting me.

>    Like I said--a system that auto-set parameters (neither
>    OS/2 or NT is such a system as far as I know[for NT--we all
>    know OS/2 isn't]) would not have "carefully selected
>    parameters" because they would have been selected and set
>    by the system, not the user.

I see.

>>I should specify, I do want it to adjust to changes, like
>>more or less par/ser ports, changes in interrupt lines etc.,


>    Agreed--but this is also a PC thing.  On an Amiga or a Mac
>    you don't have to fiddle with rediculous things like CMOS
>    settings for this stuff.

I understand the PS/2's also recognise such changes, but
I don't like IBM machines, so I don't really look into them.


>>but not the cache size or timeslices, priority etc. I most likely

>                    ^^^ Sure about that?

Yes, if I give certain priorities to applications, I do
not want to find them modified later.

>>had good reason to choose them, and I would like to continue
>>to have them choosen with proper motives, not some systems
>>programmers best guess.


>    Two different approaches, two different tastes.
>    I, personally, don't see any real-world difference
>    between the two--one is more convienient, but probably
>    get's nearly 90% as good, settings wise, as the other
>    less convenient one--but that one opens the doors to
>    users totally screwing up their settings.

I see your point. But that could easily be solved by assign different
modes of operations. This would give both type of users what they want.

>>>>If you mean it could make a suggestion
>>>>when it finds a change, I agree, but no more than that.

>>>You're thinking like a dos user.  It is not a bad idea to have
>>>the system auto-adjust and *allow* the user to fix it when you're
>>>talking about something that's suposed to be user friendly.

>>As I said above, I agree to some point, but also the user should
>>be notified of the change, so he isn't kept in the dark about possible
>>causes for changed performance. This too is user friendlyness.


>    I disagree--who wants a message saying "For performance
>    reasons, the DosWhooZiMutz parameter is being set to
>    1024.  Proceed?"--in an OS targeted at real users?  If anything,
>    OS/2 would probably have better market penetration if it
>    didn't force users to fiddle with settings to get their programs
>    to work--or work with any kind of reasonable performance.
>    While you and I would like to disable this feature, an
>    intelligent auto-settings program should be standard and
>    default.

No doubt whatsoever.

>    Most users can't deal with setting up DOS and Windows--
>    these days, they shouldn't have to fiddle to get it to work.

>    <Hint:  "Why The Mac Succeeded Even If It Isn't Perfect">

Well, I don't know about the mac, but yes most users I know
have no clue about how to setup DOS or anything.

>>>>>    Take this system, back it up, and put it on a 6 megger.  The
>>>>>    system will run so poorly and be so unstable that you'd think
>>>>>    OS/2 was written by a bunch of monkeys with typewriters.
>>>>
>>>>Let me see now. Having OS/2 installed on a 6 megger and then
>>>>adjusting the memory settings of the 16 meg system would
>>>>result in the exact same setup right?
>>
>>>    ...only if you then took *that* setup (the one optimized for
>>>    16) and moved it *back* to a 6 megger w/o *any* change.
>>
>>No, we, you and I, were talking about optimising cache settings.
>>So changing those would result in the same setup.


>    *What*?

Well, the only difference in the aforementioned system was the
amount of memory. So, the only optimisation options are those
for cache settings. (not counting adding or disposing of HPFS)
In other words, if I go from 8 to 16Meg, I would only change
the cache settings, so going back from 16 to 8 and adjusting
cache sizes would result in the same setup as when starting
with 8M.

>>>>In other words, OS/2 becomes instable if you change your
>>>>cache settings?

>>>    OS/2 behaves funny when you have low memory and are using
>>>    the HPFS.  IBM tech support themselves will recommend
>>>    not using HPFS if you have less than 8 megs and I have
>>>    been told this is not only because it slows the system to
>>>    a crawl, but because a system with the swap file on an
>>>    HPFS partition with 6 megs or less will have problems
>>>    (I was told this two seperate times by two seperate IBM techs).
>>
>>>    I think there's a comment to this effect in the faq, too.
>>
>>
>>>>I find that highly unlikely, and if indeed this
>>>>would be the case, it shows poor programming.
>>
>>>    You said it, not me.
>>
>>You can say it too if it is true. I'd kick myself if I ever did such
>>a thing, so why not tell someone else off. It should be of very high
>>priority to get this right, after all, it is one of the main
>>mechanisms in a system.


>    Which makes it interesting, doesn't it, that OS/2 doesn't
>    auto-adjust these things.  Actually, *I* prefer it that
>    way, but I think it's hurting OS/2.  Install OS/2 on
>    a 16 meg system--you'd think that it would be configured
>    for optimal performance.  Well... <no>

That indeed is a valid assumption, and I too found it
very annoying that it wasn't so.

>>>> However,
>>>>I see no reason for it to be so, since, the same effect would be
>>>>gotten when the system becomes low on memory for other reasons,
>>>>like too many jobs.
>>>>poorly) but it does not affect stability. Stability is not a
>>>>function of memory available, so the system is most likely to

>>>    Obviously, you never used the 2.0 beta, which became

>>True.

>>>    about 90% less stable when it started to use virtual memory.
>>>    This was before they plugged most of the big holes
>>>    in VM.  VM is not something simple, it is just more room

>>It is to someone who knows his bussiness.


>    Well, then IBM must not have known it very well in the pre-LA
>    2.0 beta.

I wouldn't want to go generalise a programmer or a team thereof
to IBM, but yes, he/they mucked up pretty seriously, if this
was the case.

cheers
Erik
--
Erik van Linstee   |   Delft University of Technology   |   I'll be back ...
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)