I just gave KMPlayer a shot. It actually seems to be a little slower than my usual CoreAVC/WMP11 combo (slightly higher average CPU usage). But then again, so is MPC-HC. I know people love to hate WMP, but at least on an older XP box, it's quite efficient.

Speaking of H.264, if you're running Win7, you should try the updated MS H.264 decoder (which was part of the recent platform update). It's much faster than CoreAVC and LAV Video w/ hardware acceleration. I played a few ~30 mb/s 1080p H.264 MKVs on my Pentium M @ 2.4/GTX-260 after installing the update and saw CPU usage in the 2-16% range. With LAV video decoder, processor usage ranged from 12-34%.

Unfortunately, the MS decoder doesn't provide an easy way to switch HW acceleration on/off, which sucks because I'd like to see how fast it is in software mode.

Actually I will use nothing but, WMP unless i'm on linux or OSX. I find WMP is the only media player with this kind of album view.

Hmm, it looks like Tualatin's L1 cache has some sort of hidden frequency divider. While playing around with Cachechk the other night I noticed that the L1 cache bandwidth actually increased by 657MB/s when I decreased the CPU speed from 1596MHz to 1585. The L2 cache and main memory were unaffected--they continued to rise along with the core speed.

At 1400MHz (133FSB)
L1 Write: 8402 MB/s -- 0.1 ns/byte (0.7clks)
L2 write: 6702 MB/S -- 0.2 ns/byte (0.8clks)

At 1575MHz (150FSB)
L1 write: 9022 MB/s -- 0.1 ns/byte (0.7clks)
L2 write: 7542 MB/S -- 0.1 ns/byte (0.8clks)

At 1585MHz (151FSB)
L1 write: 9084 MB/s -- 0.1ns/byte (0.7clks)
L2 write: 7594 MB/s -- 0.1ns/byte (o.8clks)

At 1596MHz (152FSB)
L1 write: 8427 MB/S -- 0.1ns/byte (0.8clks)
L2 write: 7644 MB/s -- 0.1ns/byte (0.8clks)

So 1585MHz/151FSB looks like the sweet spot. It's the highest I can go without "throttling" the L1 cache.

At first I thought that Cachechk was incorrectly reporting the L1 speed, but my favourite system benchmark 3DMark01SE consistently scored 150-200 points higher at 1585MHz. The Dragothic-Low Detail test really jumped--from 215 fps to 224. Not bad for an 11MHz decrease in CPU frequency!

I'm not sure if my VIA chipset is somehow causing this to happen or if all PIII-S CPUs throttle their L1 at higher speeds. Anyone with an i815 board care to run cachechk on their overclocked 1400-S?

I don't think there's any way the CPU can know what clock rate it's being driven to run at. I think this behavior must be caused by the BIOS. There's lots of small configuration tweaks that normally don't get exposed in the setup screen, this is probably one of them. There's probably something like an L1 wait state setting that the BIOS adjusts depending on the selected bus speed.

This also points to one way that review sites can potentially be misled by the apparent overclockability of one board versus another. The difference between boards might sometimes be from automatically throttled hidden settings in the BIOS.

I remember seeing something similar on 440BX boards. When running an ABit BX133-RAID at 133MHz bus, I noticed it was getting lousy memory speeds in memtest86. I started to wonder if it was defective somehow. There turned out to be an obscure setting in the BIOS which "fixed" it, getting the speeds back to where I expected. I don't remember what it was called, but it was some setting I've never seen on any other board. The automatic behavior on the ABit was more conservative than other BX boards I had tested, resulting in a big performance drop unless that setting was changed by the user.

Does this board support undervolting? At one time I was interested in trying to build a low power Tualatin based machine, but I never dug into it. The only Tualatin boards I have are from branded machines with no tweakability.

That makes sense. The cache-related items in the BIOS are only for ECC and enabling/disabling caches. I don't believe this board has any hidden settings, but I'll have to take a look later on. I used to have a S754 Gigabyte board that revealed hidden BIOS settings after pushing a key combination.

shamino wrote:

Does this board support undervolting? At one time I was interested in trying to build a low power Tualatin based machine, but I never dug into it. The only Tualatin boards I have are from branded machines with no tweakability.

It doesn't support undervolting. With a Tualatin installed, the voltage range is adjustable from 1.45-1.75v.

Standard Def Steve wrote:

Hmm, it looks like Tualatin's L1 cache has some sort of hidden frequency divider. While playing around with Cachechk the other night I noticed that the L1 cache bandwidth actually increased by 657MB/s when I decreased the CPU speed from 1596MHz to 1585.

It's probably ECC-correction effect caused by instability of L1 at too high clock. All on-die caches are sychronous. When L1 error occured, it can be detected by ECC-bit and processor will be stopped till error is fixing. So, you are very lucky if your core gets special clock (1596), where errors are not fatal (single bit), but they happens very often, so system doesn't falls totally. Increasing of voltage on core or extreme cooling (below zero) will prove that no divider exists and show L1-performance increase, imho.

Didn't expect to see this old thread on the first page again 🤣

posudinsky wrote:

It's probably ECC-correction effect caused by instability of L1 at too high clock. All on-die caches are sychronous. When L1 error occured, it can be detected by ECC-bit and processor will be stopped till error is fixing. So, you are very lucky if your core gets special clock (1596), where errors are not fatal (single bit), but they happens very often, so system doesn't falls totally. Increasing of voltage on core or extreme cooling (below zero) will prove that no divider exists and show L1-performance increase, imho.

I didn't even think about ECC. You're probably right on the money. I recently aquired a 1400MHz Celeron I may try overclocking to around 1.6-1.7GHz to see if its L1 starts producing errors at the same speed.