Never noticed or cared about this,

If it concerns you I would run a memory speed test over the whole 256mb addressable range.

If I had to guess the first meg or a memory whole is left out of the L2 cache for coherence, it likely doesn’t matter as much as you think.

also are you able to set L1 to write through and L2 as write back ? (Having it the other way seems strange to me)

rmay635703 wrote on 2024-03-19, 02:27:

Never noticed or cared about this, […]
Show full quote

Never noticed or cared about this,

If it concerns you I would run a memory speed test over the whole 256mb addressable range.

If I had to guess the first meg or a memory whole is left out of the L2 cache for coherence, it likely doesn’t matter as much as you think.

also are you able to set L1 to write through and L2 as write back ? (Having it the other way seems strange to me)

I don’t have any control over the caching modes in this bios. The only cache setting I have is “fast/faster” — which I assume adjusts the timings). This is really the L3 (motherboard) cache though, I had to disable the k6-2+’s L2 in order to get CTCM7 to check my motherboard cache at all.

I also have the vision top version of this board, but that doesn’t have the k6-2+ patch available. I’m not sure if it has any more options for the cache than this one does.

I’m pretty disappointed in this board to be honest, it can’t run the motherboard cache stable at 83mhz fsb so I have to run my 500mhz k6-2+ at 400mhz instead.

On my Lucky Star "5AMVP3" (that I recently upgraded to 1MB L2 cache) CTCM7 also detects a cacheable area of 255 MB. But Write Back L2 and Write Allocation are being enabled by BIOS which is more important for performance than that additional 1MB cacheable RAM.
Have you checked for an entry like "T3 sustain..."in the chipset table in BIOS? It enables / disables Write Back L2 operation.
If BIOS won´t support it you can enable Write Allocation under DOS using "SetK6".

If your RAM sticks are beyond any doubt and this mainboard is unstable even @ 83MHz I would consider a recap.

majestyk wrote on 2024-03-19, 06:37:

On my Lucky Star "5AMVP3" (that I recently upgraded to 1MB L2 cache) CTCM7 also detects a cacheable area of 255 MB. But Write Ba […]
Show full quote

On my Lucky Star "5AMVP3" (that I recently upgraded to 1MB L2 cache) CTCM7 also detects a cacheable area of 255 MB. But Write Back L2 and Write Allocation are being enabled by BIOS which is more important for performance than that additional 1MB cacheable RAM.
Have you checked for an entry like "T3 sustain..."in the chipset table in BIOS? It enables / disables Write Back L2 operation.
If BIOS won´t support it you can enable Write Allocation under DOS using "SetK6".

If your RAM sticks are beyond any doubt and this mainboard is unstable even @ 83MHz I would consider a recap.

It seems like the tagram on mine is 8ns — I kinda expected it to work at 83. I knew I’d have problems at 100, but I figured 83 would be safe.

It posts at 83, but unless I disable the external cache it just hangs with a blinking cursor when it tries to load the after post screen with all of the hardware information (right before the OS loads).

What speed tag does yours have?

Anyone know how I can figure out what megabyte isn’t being cached?

Most of my DFI MVP3 boards have 8nS TAG chips, the ASUS ALI P5A have 8nS - all of them run 100 MHz flawlessly.
If yours struggles at 83 or higher it´s either the CPU voltage regulator (-> electrolytics for the capacitor plague era) or one of the SRAM / TAG chips is defective.

WIth raising the frequency the power consumption goes up and faults in the voltage regulator circuitry become relevant.

majestyk wrote on 2024-03-19, 12:01:

Most of my DFI MVP3 boards have 8nS TAG chips, the ASUS ALI P5A have 8nS - all of them run 100 MHz flawlessly.
If yours struggles at 83 or higher it´s either the CPU voltage regulator (-> electrolytics for the capacitor plague era) or one of the SRAM / TAG chips is defective.

WIth raising the frequency the power consumption goes up and faults in the voltage regulator circuitry become relevant.

The CPU is in one of those Powerleap interposers (i.e. powered directly with a cable from the PSU bypassing the board entirely). It's been recapped (the interposer, not the board). It doesn't need to be, strictly, but the CPU is 2.0V and the board goes from 2.1V to 1.2V and skips 2.0V. The CPU itself is stable at 500MHz -- if I disable the external cache. I can try replacing the caps on the board near to the cache -- but I've never had the best luck replacing QFP chips so I'm not sure if I'd want to try replacing the cache or not. I don't have a way to verify that the replacements themselves would be any good.

What you could do is replace the TAG RAM, I have seen far more cases with defective TAG chips than cache SRAM chips.
It´s quite easy (SOJ), it´s cheap and no loss when it turns out the TAG chip was not the problem.

majestyk wrote on 2024-03-19, 13:42:

What you could do is replace the TAG RAM, I have seen far more cases with defective TAG chips than cache SRAM chips.
It´s quite easy (SOJ), it´s cheap and no loss when it turns out the TAG chip was not the problem.

Is there a way to do this without hot air?? This tag sram is in like the worst possible place for hot air. I'd have to remove the IDE/Floppy connectors and all the pin headers to even start with hot air I think.

bad TAG chip would result in not working L2, L2 detection would fail completely.
Chipsets have configurable non-cacheable windows.
Run cachechk over whole ram, it will show you which MB is non cacheable, then you can decide if its important or not.

My VisionTop S7-MVP3 (rev. G) has 2.0V so I was able to put the K6-2+ directly in it without the interposer, which freed it up to use on my socket 5 machine (now it's a Pentium MMX 233 instead of a MMX Overdrive 200). I took a chance and flashed an extra 128K EEPROM with the mod from Jan Steunebrink's repository (which doesn't specify what revision his bios is for). IT WORKS FINE on the REV G!! It's not as full featured because it's only 128K instead of the 256K rom on my ECS P5VP-A+ --- but it works at 83MHz fsb!

I settled on 192MB of memory (3x64) mostly because that's what I had other than the single 256MB stick. I tried 2x128MB but the system only detected one of the sticks. So I'm just gonna go with 192MB for now and see how that works out. I think 98SE would run slightly better with the full 256MB -- but at least I get an extra 100MHz this way!

I might attempt to replace the cache chips on the ECS board one day -- but for now it's in the questionable pile.

Thanks all,
Evan

Well, AFAIR, all tests I have seen with K6-3 and K6-2+, the external (L3) cache matters so little when the on-die cache is enabled, that I wouldn't care about that one MegaByte not being cached - unless of course it's a symptom of something going bad ...

aspiringnobody wrote on 2024-03-19, 14:00:

majestyk wrote on 2024-03-19, 13:42:

What you could do is replace the TAG RAM, I have seen far more cases with defective TAG chips than cache SRAM chips.
It´s quite easy (SOJ), it´s cheap and no loss when it turns out the TAG chip was not the problem.

Is there a way to do this without hot air?? This tag sram is in like the worst possible place for hot air. I'd have to remove the IDE/Floppy connectors and all the pin headers to even start with hot air I think.

low melt solder

aspiringnobody wrote on 2024-03-19, 14:00:

majestyk wrote on 2024-03-19, 13:42:

What you could do is replace the TAG RAM, I have seen far more cases with defective TAG chips than cache SRAM chips.
It´s quite easy (SOJ), it´s cheap and no loss when it turns out the TAG chip was not the problem.

Is there a way to do this without hot air?? This tag sram is in like the worst possible place for hot air. I'd have to remove the IDE/Floppy connectors and all the pin headers to even start with hot air I think.

Install aluminum foil tape over the sensitive stuff

H3nrik V! wrote on 2024-03-20, 06:29:

Well, AFAIR, all tests I have seen with K6-3 and K6-2+, the external (L3) cache matters so little when the on-die cache is enabled, that I wouldn't care about that one MegaByte not being cached - unless of course it's a symptom of something going bad ...

I think it's the first megabyte that isn't cached. Which is a bummer. Hard to tell for sure because cachechk doesn't check anything above 64MB. I think it's normal behavior though, both of my boards do the same thing.

H3nrik V! wrote on 2024-03-20, 06:29:

Well, AFAIR, all tests I have seen with K6-3 and K6-2+, the external (L3) cache matters so little when the on-die cache is enabled, that I wouldn't care about that one MegaByte not being cached - unless of course it's a symptom of something going bad ...

For me, I get 30FPS in Quake 640x480 with L3 disabled, and 33FPS with it on. Some of the synthetic benchmarks don't show a difference at all.

aspiringnobody wrote on 2024-03-20, 13:53:

H3nrik V! wrote on 2024-03-20, 06:29:

Well, AFAIR, all tests I have seen with K6-3 and K6-2+, the external (L3) cache matters so little when the on-die cache is enabled, that I wouldn't care about that one MegaByte not being cached - unless of course it's a symptom of something going bad ...

For me, I get 30FPS in Quake 640x480 with L3 disabled, and 33FPS with it on. Some of the synthetic benchmarks don't show a difference at all.

Ok, that's actually significant, and more than I was under the impression of.

Most ss7 boards seem to benefit from L3 where as with s5/7 it seems to be 50/50 one way or the other.