VOGONS


Reply 20 of 23, by Intel486dx33

User metadata
Rank l33t
Rank
l33t

For what its worth, Philscomputerlab did a video on this a while back. He determined that a Win98 computer with “AMD K6-lll+“ works best with (1) stick of 256mb of ram as opposed to (2) sticks of 512mb of ram. When testing in Speedsys are you guys booting off a DOS Floppy or Win98 OS ?…

So it looks like its best to use (1) stick of 256mb ram or (3) sticks of 256mb ram.
But for some reason (2) sticks of 256mb ram does not perform well ?
(1) stick of 256mb ram paired with (1) stick of 128mb ram will also perform well.
(1) stick of 128mb of ram also preforms well.

I use (1) stick of 256mb of RAM in my AMD K6 builds and they perform very stable and fast.
No problems.

Here is his spreadsheet and video:

Video link:
https://youtu.be/Jj1cVuPbW4E

Attachments

Reply 21 of 23, by Baoran

User metadata
Rank l33t
Rank
l33t

My PC is set up in old fashioned way that it boots to the dos that comes with win98se without the GUI and to load the GUI I have to give it the old "win" command. If I had 3 256MB modules I would like to test if the cpu cache would still be disabled for writing if I installed 3 modules instead of 2.

Reply 22 of 23, by Chkcpu

User metadata
Rank Member
Rank
Member

Hi Baoran,

Ik believe I know why a lot of socket 7 systems show this 512MB RAM issue.
All Award socket 7 BIOSes that I've checked have a limitation in the Write-Allocate feature. So this issue is not limited to one particular chipset, but is present on all super socket 7 boards with the Award BIOS.

The code Award uses to enable Write-Allocation on the K6 CPU series is limited to 512MB!
At this amount there is an register overflow and the code starts to count from zero again. So with 512MB RAM you get no WA and with 768MB RAM you get WA for 256MB etc.
This limitation has probably to do with the 508MB WA limit of the original K6 series and the fact that a lot of socket 7 boards couldn’t handle 512MB or more RAM anyway.
As far as I know, Award never fixed this limitation on later SS7 BIOSes, although the K6-2 with CXT core, and all K6-III / K6-2+/-III+ models, can handle WA up to 4092MB!

I have put this assumption to the test on my Aladdin V system (Jetway 542C) with 256MB RAM and a K6-III+/500. As I have no 256MB sticks, I used 2 sticks of 128MB and made 2 runs with 256MB total. First I ran Speedsys with WA On, and then with WA Off to simulate the 512MB issue.
This is what I found:

256MB_WA-ON.jpg
Filename
256MB_WA-ON.jpg
File size
56.53 KiB
Views
214 views
File license
CC-BY-4.0
256MB_WA-Off.jpg
Filename
256MB_WA-Off.jpg
File size
56.66 KiB
Views
214 views
File license
CC-BY-4.0

Exact the same issue!
So what you are seeing is indeed caused by Write-Allocation being disabled with 512MB of RAM, and I believe Phil’s benchmarks showing a performance drop with 512MB is caused by the same issue.

As most programs do more memory reads than writes, the average performance loss with WA OFF is about 10%. With WA OFF, the synthetic memory write test in Speedsys is of course a worst case scenario, that will never happen with “normal” software or games. 😉

So to avoid a performance penalty on these SS7 systems, limit the amount of RAM to 256MB or 384MB or use a utility to enable WA for the full RAM range.
A nice DOS util is K6WAON which can be found at https://www.philscomputerlab.com/k6-2-2-3-resources.html

Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 23 of 23, by Gmlb256

User metadata
Rank l33t
Rank
l33t
Chkcpu wrote on 2022-05-19, 20:15:
Hi Baoran, […]
Show full quote

Hi Baoran,

Ik believe I know why a lot of socket 7 systems show this 512MB RAM issue.
All Award socket 7 BIOSes that I've checked have a limitation in the Write-Allocate feature. So this issue is not limited to one particular chipset, but is present on all super socket 7 boards with the Award BIOS.

The code Award uses to enable Write-Allocation on the K6 CPU series is limited to 512MB!
At this amount there is an register overflow and the code starts to count from zero again. So with 512MB RAM you get no WA and with 768MB RAM you get WA for 256MB etc.
This limitation has probably to do with the 508MB WA limit of the original K6 series and the fact that a lot of socket 7 boards couldn’t handle 512MB or more RAM anyway.
As far as I know, Award never fixed this limitation on later SS7 BIOSes, although the K6-2 with CXT core, and all K6-III / K6-2+/-III+ models, can handle WA up to 4092MB!

I have put this assumption to the test on my Aladdin V system (Jetway 542C) with 256MB RAM and a K6-III+/500. As I have no 256MB sticks, I used 2 sticks of 128MB and made 2 runs with 256MB total. First I ran Speedsys with WA On, and then with WA Off to simulate the 512MB issue.
This is what I found:

256MB_WA-ON.jpg

256MB_WA-Off.jpg

Exact the same issue!
So what you are seeing is indeed caused by Write-Allocation being disabled with 512MB of RAM, and I believe Phil’s benchmarks showing a performance drop with 512MB is caused by the same issue.

As most programs do more memory reads than writes, the average performance loss with WA OFF is about 10%. With WA OFF, the synthetic memory write test in Speedsys is of course a worst case scenario, that will never happen with “normal” software or games. 😉

So to avoid a performance penalty on these SS7 systems, limit the amount of RAM to 256MB or 384MB or use a utility to enable WA for the full RAM range.
A nice DOS util is K6WAON which can be found at https://www.philscomputerlab.com/k6-2-2-3-resources.html

Cheers, Jan

Hello, Jan.

Interesting that the Award BIOS implementation for enabling the K6 write allocation was being the culprit which is news to me. I knew that there were utilities for K6 CPUs for toggling that feature but I wasn't aware that the BIOS didn't enabled it for full RAM range with later CPUs.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS