Benchmarks

“The figures are from the SDL Quake 1 ‘timedemo demo1’ benchmark running fullscreen at a resolution of 800×600.”

Interesting. Can/has this benchmark been run on an Iyonix? Or RPCEmu? I’d be willing to test RPCEMu on a reasonably fast Win7 64-bit setup (3.4GHz, Core i7-2600) for a comparison, if the benchmark is available.

I can test this on an Iyonix if required.
Is SDL Quake available for download?

To be honest, I think ArcQuake was doing about 20 fps at 800×600 on the Iyonix, so those scores are a bit lower than I’d have hoped, although I appreciate only limited optimisation will have been done. The Panda results are certainly impressive, however.

Edit – scrub that, I may well have been thinking of 640×480. It is quite a long time ago since I checked!

I’d say that 14fps is a very low score, even with softfloat. The old FQuake demo used to run better than that on a RiscPC! (OK, so it only runs at 640×480, and is only doing the BSP rendering, but you get the idea).

Do you have a quick guide or autobuilder recipe you could share for building Quake? I’ve been wanting to get either Quake 1 or 2 running for a while now, but haven’t had the time to track down an easy-to-build version. Plus I’m curious to find out exactly why it’s as slow as it is.

I’ve added the recipe for sdlquake to the autobuilder on riscos.info (r5715). It’ll be interesting to see how much faster you can make it.

I’ve also uploaded sdlquake here.

If I fire up the Iyonix, I may have the source for the 32bit build we did of !Quake, although failing that, the actual update was done by David McEwen. I haven’t spoken with him in a while, but he may have a copy of the source. I’d like a nice Quake release, too, although my motives are more along the lines of possible shifting one or two of the 4/500+ copies I have in the loft :(

Andrew, does your current release of Quake run on ARMv7?

Not to my knowledge, hence why I was referring to firing up the Iyo to try and find the source code. I can’t recall if David sent me the updated source when he produced the Iyo version for me.

Another interesting Benchmark would be the time to build a clean RISC OS ROM.
Has someone the time for this on the Panda ES?

And for that matter what has do be done to set the Pandaboard to 1.5GHz? Tweaking the MLO?

Takes about 13 minutes. That’s on a filecore formatted ssd drive.

The tweaked MLO’s are available here. Bear in mind the higher the speed the hotter it gets. Use at your own risk.

Thanks for the infos! That’s fast. At the moment I have only a StrongARM RiscPC and VirtualRPC on an old 3GHz Pentium IV (?) PC. On VirtualRPC a RISC OS build takes several hours. And my Snowball Board still waits for a port and too little spare time as probably everybody here.

And yes, I have already readed the warnings in the Panda System Reference Manual. I think I have still some of the small heat sinks I had bought for the StrongARM ;-)

Impressive, what make/model SSD drive are you using Chris?

The USB adapter is this one and this is the SSD. Any SATA II SSD should work with the adapter.

Erm, you probably don’t want to recommend “any” SSD on an OS with no Trim support (eg. RISC OS)… I’d take great care in selecting your SSDs!

I don’t think there’s too much to worry about. There’s already nearly an order of magnitude slowdown with writes on RISC OS using USB. The main benefit comes from the low latency reads. Opening folders with lots of applications in them is near instantaneous.

“Erm, you probably don’t want to recommend “any” SSD on an OS with no Trim support (eg. RISC OS)… I’d take great care in selecting your SSDs!”

What is this statement based on? Are you sure that RISC OS doesn’t reclaim areas from deleted files anyway?
I am using this pdf from the manufacturer of my recent purchase as a guide.
http://ssd.supertalent.com/datasheets/TRIM White Paper.pdf

Thanks very much for the info Chris.

Andrew, any luck finding the Quake source?

Most/many SSDs really need OS-level support for the Trim ATAPI command, as I understand it, for maintaining write performance. Without that, performance will deteriorate (often heavily) over time. Some feature more or less aggressive garbage collection which will restore performance when idle, but this is often manufacturer-specific, and/or controller specific, so you need to research properly. Earlier drives tended to have better garbage collection as XP/Vista had no Trim support. Now Win7 does (and recent linux kernels too), most drives seem to take the easy way out and assume Trim support at OS level.

It is important to remember that SSDs have fairly complex firmware algorithms for wear level management (see Ben’s posting on another thread about SD controllers). Indeed, the onboard controllers on SSDs are getting more and more impressive as time goes on, and it is the major research area for SSD tech. I seem to recall reading that one of last year’s controllers (ie. old hat now) was a dual-core ARM design with DDR3 RAM.

Trim allows the OS to work in conjunction with the controller to ensure sustained optimal performance.

As ChrisG points out, the inherent hit of USB is also fairly fundamental, but many articles show that a degraded SSD can drop write performance way, way down, well below “acceptable” thresholds.

Sorry to go on about this – we ship a LOT of SSDs both with ARMinis and RISCubes (I’d hazzard a guess that 70-80% of machines we sell have SSDs of one sort or another) so SSD stuff is pretty close to my heart!

Quake sources – no, I looked on our NAS, and only about half the Iyo stuff is on there. I probably need to fire it up when I’m over there this afternoon.

Wouldn’t it be trivial to write a “TRIMmer” application for Filecore? After all, you just have to find out the free space blocks and send the TRIM command for all those.

Chris is that the right USB adaptor you linked to? It is USB3 but the PandaBoard standard & ES seem to be USB2!

Even though it’s USB 3.0 it works fine plugged into USB 2.0.

Worth noting that USB3 adapters can require more power than is available on USB2 boards, from what I’ve seen. Caused a few headaches last year, and several USB3 devices came with a “double-headed” adapter cable for USB2 systems (but most don’t).

Ref Quake sources – couldn’t find the David McEwen 32bit version, but have found the 26bit Quake sources.

The main difference internally is that 26bit Quake used Datavox, whereas 32bit Quake did sound via SharedSound.

Will keep looking for 32bit sources, but in the meantime I’m happy to provide sources to anyone who’d like to
have a stab at it.