From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
Newsgroups: comp.os.os2.advocacy
Subject: Re: OS/2 bigot meets NT....
Date: 26 Dec 92 11:26:18 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

rsrodger@wam.umd.edu (Yamanari) writes:

>In article <1992Dec25.180324.15834@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
>>rsrodger@wam.umd.edu (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? OS/2 does
not change settings dynamically, I thought it was you who
said that. I was talking about systems in general, changing
settings when they detect changes to the hardware. There is
no previous owner involved.


>>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.
I should specify, I do want it to adjust to changes, like
more or less par/ser ports, changes in interrupt lines etc.,
but not the cache size or timeslices, priority etc. I most likely
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.


>>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.


>>>	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.


>>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.

>> 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.

>	for bugs to hide in.  So what this guy is doing is roughly
>	equiv. to running the OS/2 beta in 4 megs--with it 
>	configured for 8--so *of course* it's slow and unstable.

>>remain as stable or unstable as it was before the memory change.


	Nope.  OS/2 had more than it's share of VM induced
>	instability (still does, probably--might explain some
>	of those funny "impossible to explain" crashes, but it seems
>	pretty solid since the SP).


>>I am sure this is easy enough to understand.


>	Think a little more before such comments.

I didn't know about VM problems in OS/2, so thinking about it more
wouldn't have helped in any case.

Erik
Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy