BG> I can almost understand the 4Mb HPFS cache, but 4Mb for FAT ??
BG> Even IBM themselves recommend no more than 512Kb for the FAT cache

RS> There are no such thing as absolute numbers. What matters
RS> is if it goes significantly faster with the bigger cache.

BG> Sure, but with the law of diminishing returns, any more than
BG> say 2Mb starts to become a bit wasteful with precious RAM,

Well, we werent actually talking about a precious ram situation, in
fact quite the reverse, surplus ram, in which case if the bigger cache
does produce a very visible speedup, its definitely the way to go.

BG> especially when doubling the cache to 4Mb may only result in
BG> say a 20% increase in speed.

Like all these things, theory and reality can have a fucking great
chasm between them. When I was still getting QWK packets, with them
being produced while I was online, the bigger cache that HPFS386
allowed made a hell of a difference. Not 20% either, from memory it
was 2-3 TIMES. There is only one way with stuff like this, try it
and measure it. You can get a hell of a surprise at times.

Corse one complication is that the HPFS and HPFS386 do do things
differently apart from the maximum cache size setable, so you
also have to be careful to compare the cache sizes with say the
HPFS386, not just the small one with HPFS used.

RS> Precisely the same thing happened with the HPFS cache, IBM
RS> pontificated that the max available under the standard HPFS
RS> was plenty, no one would need more. They were wrong, some ops
RS> speedup up phenomenally.

BG> A big cache might be quite useful for a programmer or developer,
BG> but the average user shouldn't ever need more than a 2Mb HPFS cache.

Maybe. Depends on what you call an average user. In fact I'm not
even sure you are right there either. If you include users using
point systems, they are tossing their mail bundle into their mail
base. The ones with the bigger mail bundles may benefit. You would
have to measure it. I dont believe its possible to pluck numbers
like 2MB out of the air.

BG> One has to be careful not to reduce available RAM to the point
BG> that OS/2 starts using VM, which would actually have a negative
BG> effect on overall speed.

Obviously, but we are also talking about a machine with quite a lot
of physical ram for its task mix. In that situation the larger caches
may well be worthwhile. I was just making the point that you really
do have to test it, not just pluck figures on cache sizes out of the
air, coz you can get a surprise if you try it at times.

RS> And the other vital question is your task mix. If you never use
RS> the extra physical ram anyway, it ALWAYS makes sense to use it
RS> for stuff like caches.

BG> That's exactly right - IF you never use the extra RAM.

And we were talking specifically about a machine which has lots of
physical ram for the task mix.

BG> Trouble is, I played around with swapfile size a while ago,
BG> and with 16Mb, at bootup I had 13Mb free RAM.  However,
BG> disabling the swapper completely reduced free RAM to a
BG> paltry 4Mb, and some bigger apps wouldn't even load.

Thats a different issue tho. Yes, OS2 tends to basically just load
everything into physical ram at boot time, and page that out to the
swap file. BUT, much of what gets paged out to the swap file isnt
actually used, just because the user doesnt actually do stuff which
needs that stuff which has got out into the swap file. So that has
no impact on speed except during the boot phase. It may well be good
speed wise to have that stuff out in the swap file and have OS2 use
physical ram for a larger cache instead with some work. In other words
that config is noticeably faster.

Your test just demonstrates what OS2 puts in the swap file, not whats
in the swap file which gets actually used with a particular task mix.

BG> Unlike DOS or Win, at least OS/2 gives the user the ability
BG> to fine-tune his PC to suit the types of tasks he's running,

Thats crap too, particularly WRT Win.

BG> but it sure helps to know what you're doing (my knowledge of the
BG> workings of OS/2 has increased ten-fold since forking out $40 for
BG> "OS/2 Unleashed", a very fine tome of immense proportions).

Trouble is tho that some of the detail of how it does things has
changed since then |-)

And those books tend to make sweeping statements which aint necessarily
true for some not particularly unusual task mixes too. This business
about cache sizes is regularly pontificated about and its often just
plain wrong. Demonstrably wrong with particular task mixes.

BG> And a RAM disk under OS/2 (which has no 640Kb limit) ??
BG> Now I've heard everything!  |-)

RS> There are a few situations where you can know with certainty that you
RS> want to keep some stuff in ram and the cache is too stupid by itself
RS> to get as good a result. Corse what you really need is an elegant way
RS> to tell OS2 'if this gets into the cache, never replace it with anything
RS> else in the cache' OS2's cache is far too primitive for that tho.

BG> Sure, a RAMdisk can be used as a permanent cache if required,
BG> but I can't see too many people having such a requirement,

There are quite a few actually with a cache as primitive as the OS2
one. The fundamental problem with primitive caches is that they can be
very easily fooled about what is appropriate to keep in physical ram.

Take for example the situation where you repeatedly do some operation.
Say do a mail run. Even more obvious when the repeated operation happens
say hourly. Now some of the files that op uses may well be best in a
ram drive. Coz the normal cache tends to sweep those out of the physical
ram as you do other stuff between the repeated runs. If the files the
repeat op uses arent all that large, it may well be very worthwhile to
essentially tell the system to keep them in physical ram using a ram drive.

Corse, like I said, a much more elegant way to do that is to have a
much better cache which you can tell it to keep some stuff in ram as
long as it can.

The other fundamentally fucked thing about the OS2 caches is that
they are static, fixed in size. Thats totally fucked today.

BG> and certainly not as a permanent imposition on free RAM which is
BG> generally much better used for running applications.

You cant make absolute statements like that, particularly with the class
of machine we were discussing, one which has quite a lot of physical ram
for its task mix.

BG> Everybody to their own, I guess.

Nope, the answer is to carefully test what is the good config. Corse you
wouldnt have to if the OS2 cache systems werent so primitive and fucked.

--- PQWK202