On the bus speed and memory bandwidth topic: as far as CPU performance is concerned, for the likes of most (or all) Socket 7 processors as well as PII/III/Celeron and Athlon, bus speed itself makes a bigger difference than RAM speed/bandwidth (and latency is more important than bandwidth/throughput). There's around a dozen articles from the early Athlon/Duron/Pentium 4 era that deal with that transition on Anandtech, and it was mainly the Pentium 4 that benefitted from high bandwidth RAM while latency was more important on the P6 and K7 (and possibly even more so K6) with DDR configruations (even in the same chipset in some cases) often doing little better and sometimes slightly worse than PC-133 and sometimes PC-100 SDRAM.
http://www.anandtech.com/show/750 (that's just one of the threads in question, but it covers a lot of examples)
This would also give more credence to Red Hill's complaints about the 66 MHz Celeron bus vs 100 MHz SS7 in spite of the former's bandwidth advantage.
It might also mean that using CS-2 timing rather than CS-3 on SS7 boards would be significant even if synthetic memory benchmarks don't show it. (Sandra99 showed almost no difference when running my P5A-B at CS-2 -though on that note, I trued both 7.5 ns PC-133 and 8 ns PC-100 SDRAM and there seemed to be no problem at CS-2 even though they were rated for CS-3 -the PC-100 specification seems to be very conservative with its use of 8 ns DRAM among other things ... intel's documents claim that 125 MHz rated memory is needed to cope with a 100 MHz bus, but that seems like overkill -and more conservative than most video card manufacturers were doing: on the plus side, it means typical PC-100 SDRAM could cope with overclocking on SS7 boards without being one of the weak points -given you really aren't getting past 120-125 MHz in any reasonable context anyway)
On the other hand, AGP performance can be more sensitive to raw DRAM bandwidth (makes sense given the use of streaming large blocks of texture data in a serial manner) but this only really becomes a factor when you go beyond AGP 2x, so not relevant to SS7 boards or early Slot/Socket A boards (all AGP 1x or 2x) and also not a factor unless you have games and GPUs that can actually tax the AGP bus.
And on the issue of 3DNow! performance: looking over period multimedia benchmarks, the K7 (even early models) most definitely benefitted significantly from 3DNow! and in some cases gained promortionally more than SSE enabled P6 chips managed.
http://www.xbitlabs.com/articles/cpu/display/amd-athlon.html (that example seems about as dramatic as a K6-2 with and without 3DNow! with 2:1 difference)
And while there were a fair number of late 90s games still using DirectX 5.X (or not supporting Direct3D at all), a ton used DirectX 6.x, all of which should benefit significantly from 3DNow! and SSE provided the proper Direct3D drivers are installed. http://www.mobygames.com/attribute/sheet/attr … ,275/p,3/so,0a/
I'd actually forgotten that Unreal ran under directX 6 (I have Unreal Gold and it makes DirectX 7 stick in my head more). And while the Direct3D engine for Unreal is a bit buggy on some DirectX6 compatible cards (like the Riva 128 and to much lesser extent Rage Pro -messy mipmaps but non-broken lighting), it works quite well on other cards from the time including 3DFX's Direct3D drivers and Rage 128. (PCI versions of TNT, Geforce, and Matrox G400 should also be fine for SS7 motherboards, AGP ones might work on Via boards but not ALi ones, and I think AGP versions of the S3 Savage 4/Pro work fine as do Rage 128/128Pro -though installing drivers can be frustrating on some systems ... to be fair I was too lazy to really try installing Aladdin V AGP driver updates beyond what MS included in Win 98SE, so my 128 Pro experience might be exaggerated)
For a budget gaming-capable general purpose desktop+multimedia set-up with something like a Rage Pro running Unreal (in D3D or OpenGL), unless you ran at low resolution, I'd think the bottleneck would be with the video card, not the CPU. (though 3DNow! would come more into play for a Winchip2 or K6-2 266-350 ... even 350 might be overkill though)
Riva 128 wouldn't cover MPEG-2 acceleration like the Rage did, so if you remotely cared about that (for movies or some DirectX multimedia games using MPEG-1/2 video) though it would be interesting to see how well Quake 2's OpenGL 3DNow! patch favors the Riva 128 in Quake 2. (the Rage 128 Pro was nice and had mature drivers faster than the prior 128, but in 1999 it was expensive).
Off the top of my head, Voodoo Banchee and Savage 4 would've been the better budget options in 99 with a Voodoo2 being appealing if you already had a good 2D card (Rage Pro + Voodoo 2 would be a fairly balanced set-up). SLI usually wasn't practical in Baby AT motherboards either (though a few like the GA-5AA and P5A-B had multiple unobstructed PCI slots, if only 3 total). Lower-end Voodoo3 models might be appealing too, definitely more so than the Rage 128 Pro, TNT, or Matrox offerings, but it didn't have 32-bit color support or stuff like TV-out if you wanted a home theater set-up. (high-end Voodoo 3s had TV-out options but ... the Rage Pro was the best low-cost multimedia solution I know of at the time, honestly -specifically the XPert@Play form factor)
On that note, if you liked the novelty of using your PC not just as a home theater system, but also a game console though TV out (especially on a big TV with good sound system), then the Rage Pro's 3D performance might actually stretch a bit further too given you wouldn't gain any visual quality above 640x480 anyway (and 512x384 might look nearly as good depending on the scaling -I forget how well the Rage's video scaler worked ... or if you could alter the screen/overscan size for that matter; I know we used 800x600 a lot with our Radeon + TV home theater/gaming set-up, downscaled to 480i obviously and adjusted to work within TV overscan limits, but it's been too long since I tried that with the Rage)
Factor 5's Star Wars games were all DirectX 5.x based iirc, so I don't think they benefitted from 3DNow! but I do remember than running perfectly fine on both our Celeron 366 and K6-2/300 (which became a K6-2/550 at some time I don't recall ... obviously no earlier than 2000, but could have been a fair bit later than that given Dad's tendency to buy remaindered warehouse stock on clearance)
That said, a LOT of games looked like they were running fairly smoothly and looking nice if you were used to 3D consoles at the time, especially comparing N64 games to their PC counterparts. (especially given the framerate drop Factor 5 games took at times when running at 640x480 with the RAM expansion option ... or ran the faster low-res default 320x240 -though some of those upscaled to 640x480 and applied blur as primitive AA)
Oddly enough, that SS7 system got replaced with a Tualatin 1300 Celeron system later on, though it was supposed to be a Duron 1000. (the Duron had overheating issues in my case with the heat sink being used, so I ended up swapping with one of the other new builds we had going at the time) Oh, and on that note it was an Apollo Pro 133 Shuttle Spacewalker board in that set-up and in the anecdote I a few posts back on memory bandwidth. (I'd said Soyo, but got mixed up: the Soyo board was the 440ZX with Celeron 366)
Hmm:
http://vintage3d.org/rage3.php#sthash.qXlI1NZj.dpbs
Given the 320x240 Unreal performance there and the framrates Phill's Voodoo2 tests managed with a K6-2/300, I don't think the Rage Pro would benefit too much from 3DNow! in Unreal even at low res. (which would probably be a tad more fillrate bound than that page even shows given you'd really need to use the 32-bit color mode to avoid super grainy low-res dithering at 320x240, unless fillrate isn't the bottleneck at that res)