No idea if there is any merit to this, but it came up when I googled the issue:
https://forums.guru3d.com/threads/pci-latency … ormance.156780/
Supposedly increasing (yes, increasing) PCI latency (PCI TIMER in BIOS) made a difference for some people. More likely, it will do nothing or hurt performance, but it's worth a try.

Is there an option to disable the IGP in the BIOS? I have actually never used an nforce 2 IGP board so I don't know if there can be issues related to that.

Ozzuneoj wrote on 2025-10-15, 03:58:

No idea if there is any merit to this, but it came up when I googled the issue: https://forums.guru3d.com/threads/pci-latency … […]
Show full quote

No idea if there is any merit to this, but it came up when I googled the issue:
https://forums.guru3d.com/threads/pci-latency … ormance.156780/
Supposedly increasing (yes, increasing) PCI latency (PCI TIMER in BIOS) made a difference for some people. More likely, it will do nothing or hurt performance, but it's worth a try.

Is there an option to disable the IGP in the BIOS? I have actually never used an nforce 2 IGP board so I don't know if there can be issues related to that.

Chat GPT gave me these suggestions--

The nForce2 chipset was notorious for odd PCI throughput behavior depending on BIOS and driver versions. A few things can cause poor performance when using PCI (non-AGP) video cards. nForce2 was optimized for AGP 8× graphics and used an internal crossbar memory controller. The PCI bus was often hanging off the Southbridge (MCP or MCP-T) and shared bandwidth with IDE, USB, and onboard audio. So, if anything misconfigures latency timers, PCI can slow to a crawl. Let’s go through the key points that actually matter for PCI speed on those boards:

• PCI Latency Timer - Look under Advanced Chipset Features or PnP/PCI Configuration. Try setting it to 64 or 128 (instead of 32). Some BIOSes default to 32, which can severely throttle PCI bursts.
• AGP/PCI Frequency Lock - Even if you’re not using an AGP card, make sure the AGP Frequency (sometimes called “AGP Bus”) is fixed at 66 MHz (not “Auto”). On nForce2, the AGP and PCI clocks are derived together, and “Auto” may cause PCI to run at a weird async ratio (30–31 MHz, etc.).
• PCI Master 0 WS Write - Enable this if available — allows single-wait-state PCI writes and can double throughput.
• Fast Writes / Sideband Addressing - Disable both if your BIOS exposes them. They’re AGP-related, but sometimes affect internal arbitration timing.
• Spread Spectrum - Turn off for both CPU and AGP/PCI clocks — this can cause fluctuating PCI bus speed.
• System BIOS Cacheable / Video BIOS Cacheable - Disable these. They waste bandwidth and mess with caching for PCI video cards.

The only two things from that list that are visible in my BIOS are the Spread Spectrum options and Video BIOS Cacheable. I tried disabling Spread Spectrum last night and it didn't do anything. I can try Video BIOS Cacheable today to see if it works.

I did disable the IGP in the BIOS, but it seems like it is only disabled when I use an AGP card. When I use a PCI card, I see the IGP is enabled in Win98se device manager. I'll review and see if there's something else I can do to disable it when I'm using PCI video.

You see, if all of the benchmarks were consistently bad, I wouldn't worry so much about this--

I worked at it a bunch when I first saw the poor PCI benchmarks, but after an hour of messing around, it seemed like wasted time and the fact that the PCI bus hangs off the south bridge might be the issue.

Then the Visiontek 9250 PCI repeatedly produced 100+ FPS in Quake III and I started to think that the poor PCI performance might be correctable after all.

I tried again with all peripherals on the south bridge except for the IDE controller disabled, IGP disabled (aka Frame Buffer = 0MB), Spread Spectrum disabled, Video BIOS Cacheable disabled, Video BIOS Shadowed disabled.

None of those things moved the needle at all on Chris's SVGA DOS benchmark.

Maybe the reason the PCI 9250 does OK on Y2K vintage 3d benchmarks is because it has enough onboard ram to cache all the textures

To be honest, Quake engine performance on PCI GPUs is hit or miss in general. 3DMark scores show that PCI is working more or less correctly. This has something to do with cards having T&L support, because Voodoo and other pure rasterization cards are not affected. You may ask: "Why RV100 is affected?" Well, apparently it has T&L too, but depending on the driver, it can be only exposed to OpenGL. And some Win9x drivers also expose it to Direct3D.

Now, when it comes to DOS, it could be some weird issues with VESA and Mode X specifically. VESA is probably easily fixable by disabling linear frame buffer, because it's kinda unreliable on more modern chipsets and Doom benchmark, while disappointing doesn't affect gameplay, 35 fps is the game limit. I doubt that regular VGA 13h is affected in any way, so you'll probably get 100+ fps in Duke Nukem 3D.

The Serpent Rider wrote on Yesterday, 04:00:

To be honest, Quake engine performance on PCI GPUs is hit or miss in general. 3DMark scores show that PCI is working more or less correctly. This has something to do with cards having T&L support, because Voodoo and other pure rasterization cards are not affected. You may ask: "Why RV100 is affected?" Well, apparently it has T&L too, but depending on the driver, it can be only exposed to OpenGL. And some Win9x drivers also expose it to Direct3D.

Now, when it comes to DOS, it could be some weird issues with VESA and Mode X specifically. VESA is probably easily fixable by disabling linear frame buffer, because it's kinda unreliable on more modern chipsets and Doom benchmark, while disappointing doesn't affect gameplay, 35 fps is the game limit. I doubt that regular VGA 13h is affected in any way, so you'll probably get 100+ fps in Duke Nukem 3D.

Maybe. I still think it curious that the same PCI cards perform significantly better in DOS on a K6-III 400 and a PIII 800EB in both 320x200x8bit and 640x480x8bit. Seems like it's got to be related to the Nforce2 design some how.