RS> And are you saying that you have the appropriate latest HPFS386 for that
RS> too or was it one intended for use with one of the earlier versions etc ?

PE> I don't think HPFS386 is OS/2-version-specific.

And when you are getting a rather bizarre result, it might be
time to think again on that. Coz that might well be why you are.
Even if its only an unexpected quirk with a particular combination.

PE> Drivers are drivers whereas oils ain't oils.

Soorree, its nothing like that simple.

PE> I remembered that I got those sorts of results before,
PE> and didn't complete the investigation, but did remember
PE> the ballpark I had got to. That was sqpackp.

RS> From memory tho you did always see a
RS> significant improvement with HPFS386 in use.

PE> Only on the messagebase-scanning and tossing.  I still do, no change.

Did you actually test the situation you are seeing the weird
result with before ?  Surely you must have with the backup op.

PE> I do not yet have a theory to explain the observed behaviour.

RS> Until you spell out the full OS2 version and HPFS386 story,
RS> the most likely explanation is just that its showing that
RS> the HPFS386 is producing some weird results with that OS/2.

PE> Like I said above, I had the same problem, ages ago.

RS> You didnt say that above at all on the performance relativitys.
RS> Or maybe you think that para says that. Classic Paul Edwards cryptic.

PE> The para is meant to say that.  HPFS386 has always had this behaviour.

Yeah, I was essentially asking you if that rather
cryptic statement was meant to be saying that.

PE> BTW, that's a good point.  David - you said larger cache sizes don't
PE> always mean better performance, which is true, but the example you were
PE> commenting on didn't show that.  The example only showed that HPFS386
PE> was slower than HPFS for the SAME cache size for that particular operation.

Yeah, that result is quite bizarre, getting MUCH worse even with
the same size cache in a particular pair. Even more bizarre when its
with the small 2MB cache which shouldnt produce some odd effect of
shithouse algorithm trying to decide if its in the cache already etc.

PE> As for the HPFS386 story, what do you want to know?  I installed
PE> HPFS386.ZIP followed by LS30*.*, both available from here.

RS> The most obvious question is what they
RS> are supposed to be used with OS/2 wise.

PE> I know of no restrictions, and have used the same version on both before.

You STILL dont say if they are OS/2 3.x vintage tho. If they
aint, the most obvious thing to try is the 3.x vintage versions.

RS> So if you are only getting lousy performance now, thats most likely due to
RS> some interaction quirk with an OS/2 version it isnt meant to be used with.

PE> No, that's not the case.

Welp, most likely you aint meant to be able to just drop HPFS386 into
a standard Warp and carry on regardless. There other details that are
significant and thats been done in Lan/Server to deal with that obscenity
you are seeing. Coz I find it hard to believe that Lan/Server would do that.

RS> Have you tried other HPFS/HPFS386 tests with the same
RS> cache size, and never seen HPFS386 better ?  If so its
RS> unlikely to be a simple parameter adjustment problem.

PE> HPFS386 is brilliant on rescans, thanks to the indexes all being
PE> in memory.  Oh, I see what you mean, stick them both at 2 meg and
PE> do some tests.  That's a good idea, I'll try that out.  I wouldn't
PE> expect to see HPFS386 beat HPFS at that, just be the same.

It is supposed to do so, just because of the different ring level it uses.
@EOT:

---