| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.