TIP: Click on subject to list as thread! ANSI
echo: locuser
to: Paul Edwards
from: Rod Speed
date: 1996-05-25 14:38:44
subject: hpfs

PE> Well, what's the performance like after my upgrade?

Very fast after all the files went bye bye |-)

Russ uses that approach to system acceleration too, repeatedly.

PE> Well, first of all, when I write messages, and reply to
PE> them (which brings up the external editor), it just snaps
PE> up really nicely, instead of watching it load the editor.

Yeah, thats what most people comment on.

PE> I may have confused the issue by running HPFS386 on and off though.

You sure like living dangerously dont you ?

And you STILL leave out half the vital info,
you dont say which version of OS/2 you are using.

PE> Rescanning messages is virtually instantaneous, as the
PE> HPFS386 4 meg keeps all the indexes required in memory.

I think you should be publicly whipped.

PE> That leaves my overnight tasks, when I do backups, compress
PE> messagebases, etc etc, which used to take 1 hour, now it takes:

PE> Daily maintenance took 1 hour before new MB
PE> 22 mins with new MB (still HPFS)
PE> 40 mins with new MB + HPFS386 w/- 4 meg cache
PE> 40 mins with new MB + HPFS386 w/- 2 meg cache

PE> Which is a great shame!

You just need 2GB of ram and it will fly.

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.

PE> I have been able to reproduce the problem, and it goes like this:

PE> With my current (5 meg) AVTECH, I get the
PE> following results on running "sqpackp avtech":

PE> hpfs 2 meg - 13 seconds
PE> hpfs 1 meg - 13 seconds

PE> hpfs386 2 meg - 32 seconds
PE> hpfs386 4 meg - 32 seconds
PE> hpfs386 8 meg - 32 seconds

Certainly rather weird on the hpfs/hpfs32 ordering.

PE> The following sequence of commands:
PE> copy /b avtech.sqd nul:
PE> sqpackp avtech
PE> STILL made it take 32 seconds.

PE> The following sequence of commands:
PE> copy /b trading.sqd nul: [to clear avtech.sqd out of the cache]
PE> copy /b avtech.sqd nul: [about 3 seconds]
PE> sqpackp avtech [about 4.3 seconds]

PE> Makes my scanning time go from >twice as slow to about twice as fast!

PE> As far as I can tell, the operation of sqpackp is as follows:
PE> open avtech.sqd for read
PE> open avtech.~~~ for write
PE> selectively copy from avtech.sqd to avtech.~~~ [in my case, the
PE> copy will be identical, as there is nothing to be packed in most
PE> of my messagebases].
PE> delete avtech.sqd
PE> rename avtech.~~~ avtech.sqd

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

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

And that your 1 hour has dropped to 22mins with the hardware.

PE> I have played with bufferidle and maxage until I'm blue in the face,

Poor neighbours, they already know you are a loony, they
see Port Arfur, now you have gone blue in the face. I'll
make a point of watching the national news assiduously.

PE> but I can't find a way to make hpfs386 get the 13 seconds I am looking
PE> for. That 7.3 seconds clocked above, will only work if I have the whole
PE> thing in memory [I used an 8 meg cache to achieve that, on a 5 meg file].
PE> At an estimate, half of my messagebase data is in files > 8 meg.

PE> Anyone got any suggestions?

Kill yourself forthwith.

Most likely the problem is just that that HPFS386 is fucked in that config.
@EOT:

---
* Origin: afswlw rjfilepwq (3:711/934.2)
SEEN-BY: 711/934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.