SCOUG-HELP Mailing List Archives

>> Next Message >>

Date:	Tue, 18 Sep 2007 08:27:35 -0700
From:	"Jon Harrison" <jharrison@seadog.reno.nv.us >
Reply-To:	scoug-help@scoug.com
To:	< "scoug-help@scoug.com" > scoug-help@scoug.com >
Subject:	SCOUG-Help: Looking for help with VFBWC

Content Type: text/plain

On Mon, 17 Sep 2007 22:57:21 -0700, Steven Levine wrote:

>>That's a very good point and may be the reason PMMail doesn't like it.
>
>I find it odd that PMMail could be affected by it. You'll see what I mean
>when you read the link. At worst, I would think that the performance
>should not differ with and without the MTTRs set.
>
>I'm trying to visualize a memory access pattern that could cause a
>degradation, and I just don't come up with anything.

I sure was surprised to find this problem. What happens is as I
move from folder to folder within pmmail, the screen draws the
message list. There is a very noticably lag at this time. In a
folder that contains, say, more than 1000 messages, it might take 2
seconds to draw, vs. instantly without mttr set.

If I delete a message from this list, there is a several second
pause between pressing that key and the screen redrawing.

I've rem'd out the driver so I'd have to reboot to be more
specific. I thought perhaps there was a possibility that I didn't
have the frame picked correctly. I also need to test the old
version of pmmail and other apps which I will do when I get time to
fool with it. However, on the positive side, the cpu's are much
more balanced when under load. For example, when running PMINews,
since I don't delete old indexes, loading the app can take up to a
minute. The cpu load is typically 50-60 on one cpu and 15-20 on
the other. With vfbwc, the cpu's are quite close in usage. This
is why I'm interested in running this driver.

vfbwc sez this:
main memory :
524032 pages @ 0x00000000, 2096128kB -> write-back, valid
video frame buffer aperture :
4096 pages @ 0xfc000000, 16384kB -> write-combining, valid
VGA region (32 pages @ 0x000a0000, 128kB) :

I have a 16mb Matrox G400 so it looks right to me.

Divetest (mmontkowski@norman.de) produces this:

DEVESC_GETAPERTURE supported
> 4194304 byte
> At phys. address $FC000000
> Scanline length 3392 byte
> Rectangle of screen coordinates ( 0 / 1049 ) / (1679 / 0 )

I am uncertain about the 2nd report showing 4mb but perhaps that
refers to something different.

And in my bios I have chosen the smallest agp apperature, 32m.

Jon

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 18 | September | 2007 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.