Thanks for confirming the issue that I had with my Ezra-T and MTRR/FASTVID. I too hope that someone can figure the reason and we can improve Ezra-T WC mode.

VIA C3 datasheet: https://datasheets.chipdb.org/VIA/EBGA/VIA%20 … eet%20R1.90.pdf

I checked the MSRs on Ezra and Ezra-T before and after turning VGA WC on with MTRRLFE, dumping the regs with CPUCTL, and in both cases they are identical!

So either there is some undocumented register to fully activate WC on Ezra-T, or its MTRR design is underperforming.

Will post a benchmark comparison next to get a better idea.

See MSR logs attached.

And here we go, numbers are worthy one thousand pictures 😀

Used the very practical Phil's DOSBENCH. All results are the average of 3 runs. Numbers with MTRR WC on to the right.

Pure DOS on VIA PN133T + 686B, and Geforce FX5500 PCI (I'm aware the latter doesn't always shine in DOS video access, compared to GeForce2 or Voodoo3, and this intentionally shows the bigger boost when WC is on, on less than stellar VGA).

The original Ezra clearly gets a substantial performance boost with MTRR WC on (both for VGA and LFB).

For VGA, in 3DBench2 Ezra increase is in the order of 250%, and then in more intensive VGA apps (e.g. Quake) this cuts down to just 5%.

In SVGA, the performance improvement is massive and still standing in games. Quake at 640x480 goes from 23.3 to 37.0, a lovely 60% gain. Build games like Duke3D at 640x480 happily spins at 70 FPS (DNRATE in first level roof).

The Ezra-T on the other hand gets a maximum MTRR WC boost of 10% in SVGA games. Even overclocking Ezra-T to 1200, cannot catch the advantage of Ezra MTRR boost, and the Ezra 900 ends to be 25% faster than Ezra-T 1200 in Quake SVGA!

Maybe the reason C3 gets a bad reputation for SVGA performance, is that we all want the highest CPU specs (in this case Ezra-T 1000 vs Ezra 900), even when it's actually slower 😀

Pardon if this is an ignorant question as I'm rather new to C3's, but how is Nehemiah effected? Good, bad, irrelevant?

Hi Jasin, it's a good question! The Nehemiah behaves like the original Ezra, with a noticeable speed increase when MTRR WC is enabled on VGA and LFB. It also offers SSE, which might be needed in more recent nvidia drivers. The downside of the Nehemiah, is that it doesn't have the same granularity as the Ezras scaling down toward older DOS games and apps. It also doesn't play as nicely with Voodoo1/2 cards: I originally thought the issue was FSB @ 133 (which is default in most or maybe all Nehemiah), but I recently got an Ezra 866 (133 x 6.5) which I overclocked at 1000 (133 x 7.5), and I can say that Ezra at 1000Mhz can run all DOS Glide Test apps and a few DOS Glide games (e.g. Actua Soccer), while the Nehemiah at 1000 (downclocked from 1200) cannot run a single one of them. So it's not just the FSB, there must be more involved, maybe some of the internal Nenemiah optimization doesn't plays as nicely with Glide DOS drivers ? As far as I was able to test, this limitation seems to affect only DOS Glide games and apps, with Windows Glide both Nehemiah and Ezra are doing fine.

I'm planning to re-run the tests in table above with a Nehemiah at 1000 to have a direct term of comparison.

Hope these notes help!

sunmax wrote on 2024-08-27, 22:46:

Hi Jasin, it's a good question! The Nehemiah behaves like the original Ezra, with a noticeable speed increase when MTRR WC is enabled on VGA and LFB. It also offers SSE, which might be needed in more recent nvidia drivers. The downside of the Nehemiah, is that it doesn't have the same granularity as the Ezras scaling down toward older DOS games and apps. It also doesn't play as nicely with Voodoo1/2 cards: I originally thought the issue was FSB @ 133 (which is default in most or maybe all Nehemiah), but I recently got an Ezra 866 (133 x 6.5) which I overclocked at 1000 (133 x 7.5), and I can say that Ezra at 1000Mhz can run all DOS Glide Test apps and a few DOS Glide games (e.g. Actua Soccer), while the Nehemiah at 1000 (downclocked from 1200) cannot run a single one of them. So it's not just the FSB, there must be more involved, maybe some of the internal Nenemiah optimization doesn't plays as nicely with Glide DOS drivers ? As far as I was able to test, this limitation seems to affect only DOS Glide games and apps, with Windows Glide both Nehemiah and Ezra are doing fine.

I'm planning to re-run the tests in table above with a Nehemiah at 1000 to have a direct term of comparison.

Hope these notes help!

Thank you
That is interesting to know. I have a Nehemiah 1200 chip that overclocks pretty well. It runs at 1500 (15x100) stably at stock voltage on my Intel Seattle 440bx board. I did a few benchmarks with my old Voodoo 3 before I sold it, and I didn't have any issues in Windows Glide, but I'm sure I didn't even try any DOS Glide games. I might boot it up and run some DOS benchmarks though and just see what results I get with MTRR WC on/off.

Jasin Natael wrote on 2024-08-28, 13:42:

That is interesting to know. I have a Nehemiah 1200 chip that overclocks pretty well. It runs at 1500 (15x100) stably at stock voltage on my Intel Seattle 440bx board. I did a few benchmarks with my old Voodoo 3 before I sold it, and I didn't have any issues in Windows Glide, but I'm sure I didn't even try any DOS Glide games. I might boot it up and run some DOS benchmarks though and just see what results I get with MTRR WC on/off.

Please test Nehemiah for us, I am very curious. Thanks

mockingbird wrote on 2024-08-28, 15:41:

Jasin Natael wrote on 2024-08-28, 13:42:

That is interesting to know. I have a Nehemiah 1200 chip that overclocks pretty well. It runs at 1500 (15x100) stably at stock voltage on my Intel Seattle 440bx board. I did a few benchmarks with my old Voodoo 3 before I sold it, and I didn't have any issues in Windows Glide, but I'm sure I didn't even try any DOS Glide games. I might boot it up and run some DOS benchmarks though and just see what results I get with MTRR WC on/off.

Please test Nehemiah for us, I am very curious. Thanks

If I can find the time this weekend, I will get that PC out and do some testing.

Ok, C3 friends, here come the new tables for Nehemiah and Ezra w FSB 133.

Some formulas:

Nehe 1000 vs Ezra 1000 (clock x clock / same FSB / WC on) : Chris = +11% faster, PCP = +28% faster, Quake VGA = +13% faster, Quake SVGA = 20% faster

Nehe 1000 vs Ezra-T 1000 (clock x clock / FSB: 133 vs 100 [*] / WC on) : Chris = +80% faster, PCP = +88% faster, Quake VGA = +27% faster, Quake SVGA = +72% faster

Nehe 1200 vs Ezra-T 1200 (clock x clock / FSB: 133 vs 100 [*] / WC on) : Chris = +88% faster, PCP = +106% faster, Quake VGA = +29% faster, Quake SVGA = +82% faster

[*] unfortunately don't have an Ezra-T w native 133 Mhz, nor a way to change FSB in BIOS or with jumpers, Ezra-T might perform 3-5% better w FSB @ 133

In summary: when WC is enabled on VGA & LFB, Nehemiah is about 10-20% more performing in DOS VGA & SVGA than an Ezra at same clock/FSB, with a peek of 28% in PCP SVGA.

When compared to Ezra-T with WC on, the Nehemiah is about 80-100% faster at the same clock, which would seem indicative of underperforming Ezra-T MTRR implementation.

sunmax wrote on 2024-08-27, 22:46:

Hi Jasin, it's a good question! The Nehemiah behaves like the original Ezra, with a noticeable speed increase when MTRR WC is enabled on VGA and LFB. It also offers SSE, which might be needed in more recent nvidia drivers. The downside of the Nehemiah, is that it doesn't have the same granularity as the Ezras scaling down toward older DOS games and apps. It also doesn't play as nicely with Voodoo1/2 cards: I originally thought the issue was FSB @ 133 (which is default in most or maybe all Nehemiah), but I recently got an Ezra 866 (133 x 6.5) which I overclocked at 1000 (133 x 7.5), and I can say that Ezra at 1000Mhz can run all DOS Glide Test apps and a few DOS Glide games (e.g. Actua Soccer), while the Nehemiah at 1000 (downclocked from 1200) cannot run a single one of them. So it's not just the FSB, there must be more involved, maybe some of the internal Nenemiah optimization doesn't plays as nicely with Glide DOS drivers ? As far as I was able to test, this limitation seems to affect only DOS Glide games and apps, with Windows Glide both Nehemiah and Ezra are doing fine.

I'm planning to re-run the tests in table above with a Nehemiah at 1000 to have a direct term of comparison.

Hope these notes help!

I remember downclocking to 400mhz for glide games. This is with a voodoo2 and using glide patches. No problems in windows.

sunmax wrote on 2024-08-30, 03:09:

Ok, C3 friends, here come the new tables for Nehemiah and Ezra w FSB 133. […]
Show full quote

Ok, C3 friends, here come the new tables for Nehemiah and Ezra w FSB 133.

Some formulas:

Nehe 1000 vs Ezra 1000 (clock x clock / same FSB / WC on) : Chris = +11% faster, PCP = +28% faster, Quake VGA = +13% faster, Quake SVGA = 20% faster

Nehe 1000 vs Ezra-T 1000 (clock x clock / FSB: 133 vs 100 [*] / WC on) : Chris = +80% faster, PCP = +88% faster, Quake VGA = +27% faster, Quake SVGA = +72% faster

Nehe 1200 vs Ezra-T 1200 (clock x clock / FSB: 133 vs 100 [*] / WC on) : Chris = +88% faster, PCP = +106% faster, Quake VGA = +29% faster, Quake SVGA = +82% faster

[*] unfortunately don't have an Ezra-T w native 133 Mhz, nor a way to change FSB in BIOS or with jumpers, Ezra-T might perform 3-5% better w FSB @ 133

In summary: when WC is enabled on VGA & LFB, Nehemiah is about 10-20% more performing in DOS VGA & SVGA than an Ezra at same clock/FSB, with a peek of 28% in PCP SVGA.

When compared to Ezra-T with WC on, the Nehemiah is about 80-100% faster at the same clock, which would seem indicative of underperforming Ezra-T MTRR implementation.

I get about the same performance in Quake SVGA with my Nehemiah at 10x multiplier

mothergoose729 wrote on 2024-08-30, 06:54:

I remember downclocking to 400mhz for glide games. This is with a voodoo2 and using glide patches. No problems in windows.

Can confirm that the Nehemiah (probably because it has a much faster FPU compared to the Ezra-T?) must be downclocked to ~ 400 MHz / FSB100 (or even FSB66, IIRC) for older DOS Glide games.
Either way, it's not a major inconvenience and it does work fine at these lower speeds.

sunmax wrote on 2024-08-30, 03:09:

Ok, C3 friends, here come the new tables for Nehemiah and Ezra w FSB 133.
<snip>
When compared to Ezra-T with WC on, the Nehemiah is about 80-100% faster at the same clock, which would seem indicative of underperforming Ezra-T MTRR implementation.

Thanks! I purchased a Nehemiah CPU which I'll use instead of my Ezra-T... The extra granularity in reducing speed with the Ezra-T is not worth the massive reduction in performance for SVGA in DOS. Plus, you get CMOV and SSE with the Nehemiah. I plan to run it at 9x100 at boot and then increase the multiplier to 12 once the system is ready.

Yes, downclocking the FSB to 66, allows the Nehemiah to run DOS Glide games (no FSB limitation for Win Glide, possibly just multiplier reduction with SetMul). My VIA system doesn't have BIOS settings or jumpers to change FSB, so it boots at default straps (133 Mhz) with Nehemiah. Using the excellent VIAFSB I'm able (90% success rate) to switch FSB to 66 Mhz at run-time (I then have to disable sound, since ISA soundcard ain't happy at half-speed), but can then run all DOS Glide games and SDK tests.

Re: Nehemiah vs Ezra/Ezra-T speed boost : Nehemiah is much faster than Ezra-T (up to twice) clock x clock with WC enabled, but only 10-20% faster than original Ezra in DOS VGA & SVGA games. It seems for some reason MTRR WC is not fully operative on Ezra-T (it is on the original Ezra and Nehemiah, which is why their performance is closer).

I think the preference for one CPU or the other depends on the target system, games and apps. If we are targeting mostly win98se games, Nehemiah is beneficial (especially if paired with a GPU with no hw T&L, since the faster FPU of the Nehemiah will make a difference). On systems where you can change the FSB in BIOS, you can almost fine-tune the speed range to the level of Ezra (I say almost, since disabling L1 is more drastic on Nehemiah, and then DOS games -at least to my eyes- don't look as smooth as on Ezra, especially in fade-in and fade-out effects). Nehemiah SSE also allows to use later nvidia drivers, and more recent NVFlash.

On the other hand, if we are focusing on win98se w S370 or Slot1 + Slotket, then we can envision that Pentium-III 1.4S, could be even a better choice (losing earlier DOS time-sensitive games, but with maximum performance in late DOS games). If we are planning a dual CPU system, then Pentium-III becomes a must, since VIA doesn't support it (you won't get any boost w SMP in DOS or Win98, but if you also run BeOS and classic Linux on it, then you will notice the difference).

For "early to late DOS" + "early Win98SE games", I find the original Ezra (at least until we find a way to fully unleash MTRR WC on Ezra-T) to be the best all-rounder. Coupled with a GPU w HW T&L (e.g. Nvidia FX5500), the Ezra is no sloucher, it can still handle at medium details and up to 800x600, DX8.1 games like the The Hobbit (Sierra 2003) and Harry Potters (EA 2001 to 2004) at 20-30 FPS. Fully enjoyable.

I will later publish more data, to give you an early idea of Nehemiah vs Ezra 3D performance in Windows:

- 3DMark2001 SE: Ezra-T 1200 -> 3121 ; Nehemiah 1200 -> 3462 (GeForce FX5500, nvidia drv 45.23, DX8.1 - average of 3 runs)

sunmax wrote on 2024-08-30, 16:24:

<snip>
On the other hand, if we are focusing on win98se w S370 or Slot1 + Slotket, then we can envision that Pentium-III 1.4S, could be even a better choice (losing earlier DOS time-sensitive games, but with maximum performance in late DOS games). If we are planning a dual CPU system, then Pentium-III becomes a must, since VIA doesn't support it (you won't get any boost w SMP in DOS or Win98, but if you also run BeOS and classic Linux on it, then you will notice the difference).
<snip>

You're overthinking things... I don't think Nehemiah is adequate (or any C3 CPU for that matter) for anything more than DirectX 7 stuff. That means to say -- mid 90s to late 90s... Quake 2, maybe Quake 3... For DirectX 9, the sky's the limit. You can get 3-4ghz machines running Windows 98 natively. Best case scenario -- you're going to get PIII 700 speeds with the most overclocked Nehemiah.

For downclocking -- I use RayeR's SMB with Setmul... I don't intend to touch L1. C3 has a bunch of other stuff to disable to fine-tune things. I don't know what you mean when you say your sound cuts off when you lower to 66Mhz FSB. That shouldn't happen. I can lower my FSB to 50Mhz and things should work fine. PCI will run a bit under spec at that speed, but it should work.

Interesting. Gonna check C7 Eden 1200 Mhz from Wyse thin client later, to see how much it's improved, compared to Nenemiah. On the topic, I think that Ezra-T has botched compatibility with some chipsets.

Thanks, C7 numbers would be interesting!

Good point about compatibility: so far we know that on 440BX the C3s are more performant that on VIA's chipset (PLE133T and PNE133T) tested so far. We see in other Vogons tests, Nehemiah 1200 on 440BX coupled with a nice Voodoo3 + WC gets up to 70 FPS with Quake1 SVGA, while on VIA chipset and same Nehemiah 1200 Quake1 SVGA stops at 50 FPS (still an excellent result, but 40% lower). So we expected FPS to be lower, and this impacts all C3s. Would be interesting to see if Ezra-T has an additional incompatibility, which prevents WC from fully boosting video performance on VIA chipsets. We'll need to test on 440BX + Ezra-T, with WC off and then on, and measure the speed gain to verify if Ezra-T WC fully works on 440BX.

mockingbird wrote on 2024-08-30, 20:01:

I don't know what you mean when you say your sound cuts off when you lower to 66Mhz FSB. That shouldn't happen. I can lower my FSB to 50Mhz and things should work fine. PCI will run a bit under spec at that speed, but it should work.

I think SMB and VIAFSB work in a different way, SMB allows you to also set the divider and it's designed for hot-switch, so your PCI and ISA are not affected (or possibly marginally effected, if we set some FSB speed like 50). On VIA chipset, when you change the FSB with VIAFSB, let's say 133->66, ISA is also cut 50% and system will lock if a game try to use the ISA soundcard, so you have to disable sound in the game configuration. The behavior is expected, and described in one of the Voodoo compatibility threads in Vogons. The best use of VIAFSB is fine-tune (slightly overclock) the FSB, e.g. 100 -> 105 or 112, it's not meant for hot-switching FSB, I abuse it in that sense, and it's possible to switch FSB 133 to 66 (statistically 8 out 10 I get a pass, the system locks in the other 2 attempts), with the ISA limitation mentioned.

sunmax wrote on 2024-08-30, 21:23:

I think SMB and VIAFSB work in a different way, SMB allows you to also set the divider and it's designed for hot-switch, so your PCI and ISA are not affected (or possibly marginally effected, if we set some FSB speed like 50). On VIA chipset, when you change the FSB with VIAFSB, let's say 133->66, ISA is also cut 50% and system will lock if a game try to use the ISA soundcard, so you have to disable sound in the game configuration. The behavior is expected, and described in one of the Voodoo compatibility threads in Vogons. The best use of VIAFSB is fine-tune (slightly overclock) the FSB, e.g. 100 -> 105 or 112, it's not meant for hot-switching FSB, I abuse it in that sense, and it's possible to switch FSB 133 to 66 (statistically 8 out 10 I get a pass, the system locks in the other 2 attempts), with the ISA limitation mentioned.

Thanks for that... Just a correction -- I meant CPUSPD, not SetMul previously... Well, it's a combination of the three - SMB to lower FSB, SetMul for the multiplier, and CPUSPD for processor specific features.

You got four things, L2, Branch Prediction, I-Cache and D-Cache... Combine that with multiplier and FSB adjustment and you're set.

I'll also be experimenting with Esther soon. Esther was produced in Socket 478 (but near unobtainium now), and I'll throw that in my P4 system. Minimum it will do is 800Mhz. But I reckon it can also be slowed down reliably pretty well with the processor specific features. And Esther has SSE2 and SSE3 as well.

Looking forward to @The Serpent Rider's WC test later for C7.

I happen to have C7 results handy, only for Quake, specifically a C7-D 1.5GHz (15x100, multiplier locked, no P-states) on a Jetway J7F2 (CN700, AGP 8X iGPU), WC off->on (vid_wait 0):

• Quake VGA: 175.2 -> 195.3
• Quake SVGA: 32.0 -> 81.1 (2.53X)

As another data point, this is quite similar to a Pentium III 933MHz (7x133) on an Asus CUSL2-C (i815EP), ATI Rage XL AGP 2X:

• Quake VGA: 149.5 (didn't run WC on)
• Quake SVGA: 38.0 -> 82.7 (2.18X)

so the C7 results looked entirely normal to me.

Edit: Updated Quake SVGA C7 result after re-test