From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: OS/2 bigot meets NT....
Organization: University of Maryland, College Park
Date: Sat, 26 Dec 1992 15:23:41 GMT

In article <1992Dec26.112618.22243@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
>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? 


	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.


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



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



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

					^^^ Sure about that?


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



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

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



>>>>	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*? 


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


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


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


-- 
       "If you can't eat sand, why the hell are you living in a desert?"

     Equality is a delusion, suffering is a fairy tale and God is a fantasy.
       Blaming society for inequality is like blaming the sky for rain.
Newsgroups: comp.os.os2.advocacy