Cpu multiplier jumper?

It's at 5.5, of course. I've already verified everything with Aida64, CrystalCPUID, etc. The CPU is running at 550 MHz, RAM is at 100 MHz CL2.

Your not exceeding cacheable ram limits are you?

VIA MVP3 with Write Back cache strategy set in BIOS […]
Show full quote

VIA MVP3 with Write Back cache strategy set in BIOS

With 512 kB Level 2 Cache, 64 MB are cacheable
With 1024 kB Level 2 Cache, 128 MB are cacheable
With 2048 kB Level 2 Cache, 256 MB are cacheable

VIA MVP3 with Write Through cache strategy set in BIOS (2-3% slower system)

With 512 kB Level 2 Cache, 128 MB are cacheable
With 1024 kB Level 2 Cache, 256 MB are cacheable
With 2048k B Level 2 Cache, 512 MB are cacheable

The cacheable RAM limit should not be important for an AMD K6-(2|3)+ CPU, since it has on-die L2 cache.
But still, no, I'm only using 128 MB of RAM (with a 1 MB motherboard cache).

Ok, I wasn’t sure how that worked exactly for K6-2+ /K6-3 . I thought if you were still using onboard L2 then on-die becomes L3 cache.

Yes, it becomes L3. But on a K6-2/3+, even if you disable the motherboard cache, the performance impact is minimal.

OK... problem..... solved?!
You guys won't believe this: it was because of the... USB 2.0 PCI card. 😮
I found these charts and I thought that the Quake 2 software mode benchmarks were particularly of interest, since I could eliminate potential GPU related issues (I did suspect all along that this was a CPU, not a GPU problem).
So I ran the Q2 640x480 timedemo benchmark in software mode, and sure enough... my result was extremely weak: 14 FPS (as opposed to 23.7, as seen on the chart for a K6-2+ 550MHz CPU).
Since now I was sure that this was indeed a CPU issue, I thought I'd start from scratch and removed everything (including the soundcard and the PCI USB2.0 adapter). Tested again and... 23.9 FPS 😀.
I then proceeded to adding back the soundcard, tested again (high sound quality setting) and... 21.7 FPS (lower, but still acceptable). After that, I added the PCI USB2.0 card and again the framerate plummeted to 13.9 FPS. I then removed it again: 21.5 FPS. Weird or what?

So I now redid all the benchmarks without the USB 2.0 PCI adapter and the numbers are:

GLQuake timedemo (OpenGL / 1024 x 768): 127 FPS
Quake 2 timedemo (OpenGL / 1024 x 768): 67.4 FPS
Expendable timedemo: 30.8 FPS (average)
3DMark 2000: 2382 points

I don't know about you, but I'm still trying to understand why the PCI USB adapter has such an impact on the CPU throughput. I'm guessing it's a BIOS bug that was never solved...

Probably the USB card uses the same IRQ as the video card. On all systems I've built with an USB card added, it seems to always prefer using the VGA IRQ.

Yes, but why would it affect the software mode? Based on everything I've seen, the CPU performance is affected, not particularly the video card.

Because software mode just writes to the frame buffer. I don't think the IRQ is ever used then.

I tested your theory with the Aida64 CPU tests (which don't use the videocard at all).
Memory tests don't seem to be affected by the PCI USB adapter. However all CPU tests (Queen Benchmark, PhotoWorxx, ZLib, AES, etc) are taking a 30 - 40% hit with the adapter.
Also, I checked the adapter IRQ and it's 9. The video card runs on 11.

Try to deactivate the USB adapter in Windows, so that it is not used. If the issue is still there then, it's hardware-related. If not, it's driver-related. I guess you have NUSB installed, too?

I think I know exactly why it is causing the lower scores with the USB card installed.

USB polling. It can use a decent amount of CPU and especially for a lower speed CPU, the CPU usage needed is going to be significant.
If you aren't using the USB ports for anything, it may not affect it as much.. at least with a faster CPU, but no idea on a slower CPU such as the K6-2+ or similar.

Default polling rate should be 125Hz which is nothing but when raising to 1000Hz, a Phenom x4 965 can use 8% CPU usage and that is magnitudes faster than the K6-2+.
https://www.mikemartin.co/system_guides/hardw … se/polling_rate

I remember this being a big thing back in the day.. raise the USB polling rate and you get smoother mouse movement but you had to juggle it with how much of a CPU performance hit you were willing to take.

Could even be a weird compatibility issue with that particular USB chipset.

@cyclone3d: Yeah, I also remember fiddling with the MouseRate program back in the day. Good idea regarding the USB polling. However, I think that it should only be a concern when having a USB device actually connected in one of the ports.
@derSammler: yes, I have nusb36 installed. Tried your suggestion, disabled everything related to the USB adapter in device manager, including the controller itself and rebooted Windows after that: same problem. Seems like for now the only solution is to physically remove the adapter from the PCI slot.

I've observed this exact same behavior on my Tualatin so it takes a fairly decent amount of power before the performance hit of the USB drivers becomes negligible (well technically it's not that bad on the Tualatin, but it's definitely observable). I've found that disabling the card in device manager to be just as good as physically removing it, so if you only need USB 2.0 on occasion it would be a good idea to just disable it there and enable it when needed. Note that your USB 2.0 card has two USB 1.1 controllers as well which you may want to disable.

derSammler wrote on 2020-03-22, 09:56:

Probably the USB card uses the same IRQ as the video card. On all systems I've built with an USB card added, it seems to always prefer using the VGA IRQ.

The USB card doesn't prefer anything. There are 4 IRQs for PCI/AGP. Each slot has the 4 IRQs in a different order, typically they're rotated going top to bottom. I.e. AGP slot would be ABCD, first PCI slot is BCDA, second is CDAB, and so on. (Most boards use either that layout or the first PCI slot may be ABCD like the AGP slot.) Some boards document the IRQ layout in the manual, but others you'd just have to plug and device in and see where it lands.

USB 2.0 cards typically have 3 "functions", where each function gets one of the IRQs. On the cards that I have the USB 2.0 controller is on the third function so it will get the 3rd IRQ. Functions 1 and 2 are the USB 1.1 controllers. What you'll notice here is that using 3/4 of the IRQs means that it takes planning to avoid the VGA IRQ if that's what you want to do. One thing you can do is disable the 1.1 controllers and only use the add in card for USB2 devices keeping the IRQs free. But do note that given the layout of the functions if you want to avoid IRQ conflicts you have to imagine that the card is two slots down from where it's actually plugged in.

What all that said I don't believe I've seen any performance issues with sharing the VGA IRQ (IIRC the IRQ is only used in a very specific circumstance but I could be misremembering). Still if you understand PCI IRQ assignment you can eliminate IRQ sharing entirely and that's fun to see even if the performance benefit is debatable.

What chipset does the USB 2.0 card you have use?

Blzut3 wrote on 2020-03-22, 20:49:

I've observed this exact same behavior on my Tualatin so it takes a fairly decent amount of power before the performance hit of the USB drivers becomes negligible (well technically it's not that bad on the Tualatin, but it's definitely observable). I've found that disabling the card in device manager to be just as good as physically removing it, so if you only need USB 2.0 on occasion it would be a good idea to just disable it there and enable it when needed. Note that your USB 2.0 card has two USB 1.1 controllers as well which you may want to disable.

Yes, I've disabled the USB 1.1 controller since the beginning, along with the Serial and Parallel ports. I would have used the 1.1 controller, but unfortunately I don't have a USB bracket for it.

cyclone3d wrote on 2020-03-23, 00:36:

What chipset does the USB 2.0 card you have use?

It's a NEC 0720101GJ chipset.

Further updates: Meanwhile, I started playing with another SS7 board: DFI P5BV3+. This one does not work at all with the PCI USB 2.0 adapter. The Windows installer throws a BSOD during hardware detection (even though it doesn't even have a driver for it). Without the USB 2.0 adapter, the installation works perfectly. Also tested adding it after the installation: Windows freezes during boot. I checked the IRQ table, all devices have a separate IRQ, so there's no IRQ conflict going on. It just seems that the SS7 boards don't like this adapter at all (and some are worse than others).
On the bright side, this other board works perfectly too, didn't have any weird AGP bugs (tested it with a GeForce 4 Ti 4200) and managed to overclock the CPUs to 600 MHz with the default 2.0V. So now I have two SS7 boards, both with 600 MHz K6-2+ CPUs. One of them will run with a Voodoo 3, the other with a GeForce 2 MX 400. #MeHappyAlthoughNotSureWhy

Both of your boards use the VIA MVP3 chipset which is somewhat problematic in my opinion.

ALi Aladdin V is somewhat worse when it comes to AGP compatibility but much better and more stable regarding IDE, PCI, IRQ steering etc.

I don't know... Back in 1999 I was using a full ATX SS7 Ali Aladdin V board (beautiful board, if I might add, also had ESS Solo-1 onboard sound and an SB-Link connector). Can't believe I sold it for 15 bucks.
Still,I had all sorts of issues with it (RAM compatibility problems, AGP freezes, etc). It's also true that I was 15, so my debugging skills were limited back then (although, AFAIK, I tried everything to make it more stable, including BIOS updates, multiple driver versions, playing with the AGP BIOS settings, etc).
All in all, the current experience with VIA MVP3 boards is much better than my old experience with ALI Aladdin, I find them to be very stable, I would go as far as to say that they are almost as stable as my 440BX boards (blasphemy, I know). 😁