Note that those figures are for the same 100MHz FSB, which really shows how slow the 693A is. I was referring to 133MHz on the 693A vs 100 on BX, which the BX still wins (!) but with a reduced margin.

Curiosity after a comparison of fsb 100 vs fsb 133 made me collect PIII 600MHz cpu's.
Here some scores made with an ASUS P3V4X :

CPUMark2002 score // cpu
1527 // 600 MHz SECC /100
1546 // 600B MHz SECC /133
1599 // 600E MHz SECC /100
1623 // 600EB MHz SECC /133

3DMark99 cpu score // cpu
8958 // 600 MHz SECC /100
9083 // 600B MHz SECC /133
9151 // 600E MHz SECC /100
9397 // 600EB MHz SECC /133

3DMark2000 cpu score // cpu
240 // 600 MHz SECC /100
259 // 600B MHz SECC /133
306 // 600E MHz SECC /100
317 // 600EB MHz SECC /133

Although the difference made by the 100=>133 fsb is clear I am not sure if it is very significant in real life ?
edit
PS Is there a benchmark that shows the advantage of fsb 133 over 100 more clearly ?

Not only depends in how slow is the chipset, also how it was implemented, such case happed on the VIA Apollo Pro 133A (694X) which some boards performed quite bad despite using that chipset at the point it was no faster than 693A or even slower than it, notable examples of such boards are the Jetway 994AN and the Biostar M6VCG, 693A should be avoided unless you really can't affrod a 440BX or 694X. Good VIA 694X would be the ASUS CUV4X series, Gigabyte GA-6VX7-4X (posibly one of the fastest 133A boards acording to tom's hardware and anandtech), ASUS P3V4X, MSI MS-6309 and the QDI Advance 10

Comparing apples to oranges (in every sense), a raspberry pi 3b on a per-core basis is roughly identical to a Celeron 700 in CPU performance according the multi-threaded HWBot Prime benchmark.
- https://hwbot.org/hardware/processor/broadcom_bcm2837 (divide by 4 to get per-core score).
- https://hwbot.org/hardware/processor/celeron_700mhz/

Running Half-Life 1 (xash3d with original data files) on the Pi3b sustains 70 fps (capped by vsync), and only dips periodically on complex scenes. This is rendering the original textures, audio, and game logic at 1280x720. xash3d is single threaded, so the pi isn't cheating the celery using its extra cores (indeed, three cores sit idle).
Although different in every way and generations apart, the fact these systems are roughly similar in processing power yet one is an order of magnitude slower in this test has me agreeing with those who suspect some underlying hardware/configuration issue that is massively bottlenecking your system. Has anyone else reported HL1 frame rates on a Celeron 700?

krcroft wrote:

Comparing apples to oranges (in every sense), a raspberry pi 3b on a per-core basis is roughly identical to a Celeron 700 in CPU […]
Show full quote

Comparing apples to oranges (in every sense), a raspberry pi 3b on a per-core basis is roughly identical to a Celeron 700 in CPU performance according the multi-threaded HWBot Prime benchmark.
- https://hwbot.org/hardware/processor/broadcom_bcm2837 (divide by 4 to get per-core score).
- https://hwbot.org/hardware/processor/celeron_700mhz/

Running Half-Life 1 (xash3d with original data files) on the Pi3b sustains 70 fps (capped by vsync), and only dips periodically on complex scenes. This is rendering the original textures, audio, and game logic at 1280x720. xash3d is single threaded, so the pi isn't cheating the celery using its extra cores (indeed, three cores sit idle).
Although different in every way and generations apart, the fact these systems are roughly similar in processing power yet one is an order of magnitude slower in this test has me agreeing with those who suspect some underlying hardware/configuration issue that is massively bottlenecking your system. Has anyone else reported HL1 frame rates on a Celeron 700?

It looks like it will cost me $40 one way or the other to prove it out. That's for a new CPU. With a 133 FSB, at least the memory will be working properly.

Gahhhrrrlic wrote:

It looks like it will cost me $40 one way or the other to prove it out. That's for a new CPU. With a 133 FSB, at least the memory will be working properly.

or you know, fix the drivers

krcroft wrote:

Comparing apples to oranges (in every sense), a raspberry pi 3b on a per-core basis is roughly identical to a Celeron 700 in CPU […]
Show full quote

Comparing apples to oranges (in every sense), a raspberry pi 3b on a per-core basis is roughly identical to a Celeron 700 in CPU performance according the multi-threaded HWBot Prime benchmark.
- https://hwbot.org/hardware/processor/broadcom_bcm2837 (divide by 4 to get per-core score).
- https://hwbot.org/hardware/processor/celeron_700mhz/

Running Half-Life 1 (xash3d with original data files) on the Pi3b sustains 70 fps (capped by vsync), and only dips periodically on complex scenes. This is rendering the original textures, audio, and game logic at 1280x720. xash3d is single threaded, so the pi isn't cheating the celery using its extra cores (indeed, three cores sit idle).
Although different in every way and generations apart, the fact these systems are roughly similar in processing power yet one is an order of magnitude slower in this test has me agreeing with those who suspect some underlying hardware/configuration issue that is massively bottlenecking your system. Has anyone else reported HL1 frame rates on a Celeron 700?

I haven't used a Celeron 700, but with a P3 750 it can still clearly drop to 30s on harder scenes, Half life 1 can be very hard on hardware from the time, and since there are so many different patch versions and the timedemo function is not very reliable it's a little difficult to compare, in any case another user had posted a timedemo and I shared some of my results in this post with the p3 750 Half-Life Performance Issues
but I can't say it's particularly bad in terms of stutters or anything.

I would think on optimized code the pi 3b would be clearly faster even on ST,
actually, I think there are quake 3 arena ports for the pi, I wonder how it would look on our quake 3 arena timedemo thread!

SPBHM wrote:

another user had posted a timedemo and I shared some of my results in this post with the p3 750 Half-Life Performance Issues
but I can't say it's particularly bad in terms of stutters or anything.

I dropped game.dem in my valve/ directory, and ran playdemo game from HalfLife's console, but unfortunately it just eats it without any response (good or bad).
This is despite xash3d actually supporting recording and playback .dem files. Just running >playdemo without any arguments returns "Usage: playdemo <demoname>". Is there anything else I can run?

SPBHM wrote:

I think there are quake 3 arena ports for the pi, I wonder how it would look on our quake 3 arena timedemo thread!

Score: 145.7 fps (seizure-inducing.. had to close my eyes when running it again)

I built a fresh ioquake3 using gcc 8.3 natively on the pi3b with the following optimizations: CFLAGS=-Ofast -marm -mabi=aapcs-linux -march=armv8-a+crc -mtune=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -funsafe-math-optimizations -mvectorize-with-neon-quad -pipe

Quake3 was launched with all of these these arguments:

1QUAKE3_ARGS_GAME="+set fs_game \"baseq3\""
2QUAKE3_ARGS_VIDEO_QUALITY="+set r_vertexLight \"0\" +set r_lodbias \"0\" +set r_picmip \"0\" +set r_texturebits \"32\" +set r_textureMode \"GL_LINEAR_MIPMAP_LINEAR\""
3QUAKE3_ARGS_VIDEO_FOV="+set cg_fov \"90\""
4QUAKE3_ARGS_TIMEDEMO="+timedemo \"1\" +set demodone \"quit\" +set demoloop \"demo four; set nextdemo vstr demodone\" +vstr demoloop"

This is per the script here: https://gist.githubusercontent.com/Technologi … 372140eeeb7/raw

Note this score is significantly faster than circa-2016 scores here: https://www.technologist.site/2016/11/05/how- … y-pi/6/#Results, which max-out in the 70-fps range. I believe ioquake3's graphical engine was re-written after 2016 in addition to improvements in gcc, the Linux kernel, and the pi's framebuffer and GLES drivers since then.

It's pretty amazing given the hardware is drawing 2.7 watts at the wall while running the demo (CPU, GPU, HDMI output, etc); which drops back to ~1.4 watts when idle.
(sorry for derailing this thread - if there's a better place to drop these results let me know and I'll move this post)

my stake goes to the celeron in this match. despite its slow 66fsb, its 128k l2 cache is a hell lot faster than the pentium2's external l2 cache that runs at half speed and is only slightly faster than pc133 sdram, and accessing ram through fsb is only needed at a cache miss. also its sse instruction helps pushing fsb bandwidth utilization to the limit.
still, it requires a board with fast sdram performance such as the 440bx. if you have a board with poor sdram performance, sis620/630 for example, the celeron would surely suffer more than the pentium.

Re: Fixing drivers

I'll try different graphics drivers if you think it will make a difference but honestly it doesn't make sense to me. I ran UT in software emulation, which ignores the video card altogether and it ran like ass. 700 MHz of any kind of garbage should still be enough to keep the gameplay smooth in the first level of deathmatch. With the VIA drivers definitely installed, the only thing I can think of is either the CPU has some design flaw that needs drivers to fix or the hard drive is too slow but even then that wouldn't explain a fully cached area lagging so are we saying here that 700 MHz of CPU-only just can't run UT at 20 FPS consistently? I just don't buy it but like I said, I will be scientific about this and try everything.

Any chance the Celeron runs too hot and throttles?

Gahhhrrrlic wrote:

With the VIA drivers definitely installed

installed doesnt meant working, 4in1 drivers had ton of problems and were graphic card specific, aka some versions worked only with some versions of ati/nvidia drivers
try running 3dmark99

H3nrik V! wrote:

Any chance the Celeron runs too hot and throttles?

no such thing in this generation of cpu

Unreal Tournament is very AGP/memory intensive. The 66Mhz FSB is really hurting you, along side the slow chipset and the likely poor implementation.

There is also the fact that the game ran slow on original hardware by todays standards.

Looking at this test you can see that the game is already starting to get bandwidth starved with a P3 700Mhz on the 440BX chipset with 1999 era cards. The three voodoo 3 cards basically have the same score:

https://www.anandtech.com/show/429/11

Also note that those are average framerates so you can probably cut those in half with a lot of action on the screen.

Here the test is with a Celeron 500 on 440BX, same thing (but slower ofc):

https://www.anandtech.com/show/429/16

krcroft wrote:

I dropped game.dem in my valve/ directory, and ran playdemo game from HalfLife's console, but unfortunately it just eats it with […]
Show full quote

SPBHM wrote:

another user had posted a timedemo and I shared some of my results in this post with the p3 750 Half-Life Performance Issues
but I can't say it's particularly bad in terms of stutters or anything.

I dropped game.dem in my valve/ directory, and ran playdemo game from HalfLife's console, but unfortunately it just eats it without any response (good or bad).
This is despite xash3d actually supporting recording and playback .dem files. Just running >playdemo without any arguments returns "Usage: playdemo <demoname>". Is there anything else I can run?

SPBHM wrote:

I think there are quake 3 arena ports for the pi, I wonder how it would look on our quake 3 arena timedemo thread!

Score: 145.7 fps (seizure-inducing.. had to close my eyes when running it again)

I built a fresh ioquake3 using gcc 8.3 natively on the pi3b with the following optimizations: CFLAGS=-Ofast -marm -mabi=aapcs-linux -march=armv8-a+crc -mtune=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -funsafe-math-optimizations -mvectorize-with-neon-quad -pipe

Quake3 was launched with all of these these arguments:

Copy code to clipboard

1QUAKE3_ARGS_GAME="+set fs_game \"baseq3\""
2QUAKE3_ARGS_VIDEO_QUALITY="+set r_vertexLight \"0\" +set r_lodbias \"0\" +set r_picmip \"0\" +set r_texturebits \"32\" +set r_textureMode \"GL_LINEAR_MIPMAP_LINEAR\""
3QUAKE3_ARGS_VIDEO_FOV="+set cg_fov \"90\""
4QUAKE3_ARGS_TIMEDEMO="+timedemo \"1\" +set demodone \"quit\" +set demoloop \"demo four; set nextdemo vstr demodone\" +vstr demoloop"

This is per the script here: https://gist.githubusercontent.com/Technologi … 372140eeeb7/raw

Note this score is significantly faster than circa-2016 scores here: https://www.technologist.site/2016/11/05/how- … y-pi/6/#Results, which max-out in the 70-fps range. I believe ioquake3's graphical engine was re-written after 2016 in addition to improvements in gcc, the Linux kernel, and the pi's framebuffer and GLES drivers since then.

It's pretty amazing given the hardware is drawing 2.7 watts at the wall while running the demo (CPU, GPU, HDMI output, etc); which drops back to ~1.4 watts when idle.
(sorry for derailing this thread - if there's a better place to drop these results let me know and I'll move this post)

interesting results, it's certainly not doing too badly, 145FPS would take a very fast P3 to achieve I think, and at that point you could well be GPU limited,
but realistically you are comparing with software stuck in 1999/2000 with the more recent port receiving lots of optimizations, which I don't know if it would ever make for a fair comparison, still I would expect the Cortex A53 at 1.4GHz to do well against Coppermine
for example on geekbench 2 the pi3b is faster than a 1GHz p3 Coppermine on most single thread tests
https://browser.geekbench.com/geekbench2/comp … 2667199/2596704
but yes, when you look at power draw it gives some perspective.

I don't think Celeron 700 and rpi 3b are all that comparable.

regarding half life 1:
I just use timedemo game.dem and it works, but as I said it's very sensitive with the hl version, and even with the resolution I use, to play it back, I can only say that it works fine for me with 1.0.8, but I'm not surprised that it doesn't work with a port/new engine, the demo was just mostly the initial fights when you encounter the first "Houndeyes" until you enter some sort of sewage pipe, on that area of the map with the enemies it drops often to low 40s while fighting with my p3+v4 pci (it's very variable and jumps to the FPS cap also often)
basically starting at this part https://www.youtube.com/watch?v=4vFZ7PZ0bwc&f … youtu.be&t=1130

back to OP, UT99 is CPU hungry no doubt, on my p3 @840 with a V4 4500 pci (glide, 16bits) I get 39FPS avg and 27.2 min at 1024x768, and 43.51FPS avg, 28.2min at 640x480, so I think it's fair to say it's very CPU limited even with a V4, and the p3 @ 840 (112FSB on 440BX) should be a decent amount faster than a Celeron 700
but this demo is very hard, it feels like it runs better than that on average, but I can't say I have played it all that much.

looking at this
https://www.tecchannel.de/a/test-duron-1300-g … leron,401594,11
Celeron 800 drops the average to 28FPS with a Geforce 2, and that's compared to over 45AVG with a 1.2-1.3Ghz CPU
(you can download the utbench demo here Looking for UTBench.dem for Unreal Tournament, I would think it's the same used by that website?)
I think all things considered it's not unexpected for the Celeron 700 to perform poorly on this title, and with a Radeon 9500 and newer drivers, it could be even worse

Another mystery solved. I bought a P3 733 chip with 133 fsb. I did this to keep the MHz speed as close as possible to what I had before. Guess what... the Celeron is a complete dog. The P3 wipes the floor with it, probably because of how it's also affecting memory and bus speeds to boot. Everything runs smooth at 1280 resolution. I may even put Halo on this machine.

This is like deja vu for me. I just had a breakthrough with another machine... a P133 that was failing to run something as crummy as Wipeout XL at 320 resolution... that is until I swapped it with a replacement CPU of the same type and speed and found out the first one must have been damaged but still working. Again the difference was night and day.

I have new respect for CPUs. It's not all about the GPU and RAM if your CPU blows chunks and the speed is no indication of anything. 700 sounds like a lot but my (properly working now) P133 can do a better job with UT99 and a voodoo card... barely.

This makes zero sense, especially part about replacing with same P133 cpu and seeing difference.

And a P133 cannot outperform a celeron 700MHz unless something is very wrong.

Deksor wrote:

And a P133 cannot outperform a celeron 700MHz unless something is very wrong.

I feel like something got lost in translation. The comment about the P133 was completely unrelated to this topic. All I meant was I had a broken P133 chip that I replaced and it made a night and day difference on THAT computer, showing me how importance CPU performance is.

On this machine I make no claims that a P133 outperforms a Celeron 700. I do claim that a P733 improved my system performance by a phenomenal amount, from basically being crippled for all but dos games to being able to run Deus Ex, TR:AOD and other demanding stuff like it was nothing.

Gahhhrrrlic wrote:

All I meant was I had a broken P133 chip that I replaced and it made a night and day difference on THAT computer, showing me how importance CPU performance is.

Afaik there are no CPU failure modes resulting in degraded performance in this Pentium generation.

rasz_pl wrote:

Gahhhrrrlic wrote:

All I meant was I had a broken P133 chip that I replaced and it made a night and day difference on THAT computer, showing me how importance CPU performance is.

Afaik there are no CPU failure modes resulting in degraded performance in this Pentium generation.

There is now... I have the proof. I can mail it to you if you like - a functioning CPU that does everything you would expect of it without any blatant symptoms of damage... just very slowly. The replacement CPU was the same model and revision and fixed the problem with no other hardware changes whatsoever.