Benchmarks

Thanks! Meanwhile I updated to the latest ROM…no change…so there’s really a big difference between Panda and Panda ES and I guess that’s somehow the RAM to VRAM copy capability while using ARM-registers to copy content.

Some months ago I reported about that here when I collected data for my Memory Speed Benchmark, but almost forgot about it ;-) …so that seems to be fixed with the ES. I could use NEON commands to speed that up, but then we won’t be able to run that on the R-PI.

To confirm and if you got some time (lots of numbers to note…you can also send it to me by mail, not to flood the forum here…) may be you can run my benchmark on your board (at 1.5 GHz is okay), it can be found here

@Jeffrey or Chris: Some results (or errors ?) from the R-PI with the !FireBench (see my post before…) ?

Chris: Some results (or errors ?) from the R-PI with the !FireBench

Raspberry Pi result: 25.53 seconds 160 frames/sec

Using version 1.1 of Richard Spencer’s benchmarking programme

Could someone point me to a link for this? The one given is now dead. I had a quick look through SpriteExtend’s whacky code generator and it looks possible to speed up the icon plotting in the < 24bpp colour depths.

version 1.1

Not v. 1.01, then?

Thanks for the web archive link, however the ZIP file of the program doesn’t seem to be in the archive, only the text of the webpage.

I just wanted to see how the icons were being plotted (transformed or scaled) to figure out which code path the slowness is in.

Could someone point me to a link for this [RISCOSMark]?

Here

Benchmarks updated for Raspberry Pi now that SDFS is working.

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02

Five of the benchmarks were very dependent on the screen mode used and so I have repeated them at different screen resolutions:

* – 1920 × 1080 C16M
+ – 1600 × 900 C16M

I’m not quite sure how to read the impact of SDFS from those tables. The sort of timings I’ve measured look like this:

So I wasn’t actually timing a (potentially slow) USB SD card reader, the SCSIFS timings are from a USB hard disc, which should maximise the transfer speed. So that SDFS isn’t disadvantaged by the slow process of flash memory erase, the timings are all for reads, not writes.

These results do seem to suggest that we’d better off changing the recommendation to boot from SD cards rather than USB sticks, on speed grounds. Just need to figure out how best to do that now…

boot from SD cards rather than USB sticks, on speed grounds

not everyone will be using class 10 SD cards though. Under ‘HD’ I was testing the fastest drive, usually a direct connected HDD.

The most convenient method for most individual home/development users is probably going to be doing everything via a single SD card, isn’t it? This is what other distros are based on AFAIK.

1. Are speeds for SD card reads (and maybe writes too, in this case) similar under RISC OS and Linux?
   • And won’t SD card accesses typically be more frequent under Linux than RO?
2. If the use of USB sticks or spinning platter drives provides a noticeably faster experience to the user, this could be mentioned as an option.

“The most convenient method for most individual home/development users is probably going to be doing everything via a single SD card, isn’t it? This is what other distros are based on AFAIK.”

Doesn’t this then leave the user writing temporary files – the content of !Scrap – to their SD card?
Isn’t this an instance where the build needs to automatically create a RAM disc and place those transient items there?

I’m aware of the habits of certain applications, like Netsurf, of saving items for future sessions in Scrap but I can see no reason for those retained items not being placed in Choices if they are infrequently written and in a truly transient location if they are frequent (many times per session) writes.

I was thinking recently that a typical small cased beagle would only need the SD, but then recalled the !Scrap issue. So I moved on to the consideration of the same build with a small form factor USB memory device e.g. (SanDisk Cruzer® Fit™ 4GB USB Flash Drive (Maplin A85KZ) 4.99)

For the average new user an image on SD that creates the other items on a second device – if available – would seem ideal. The Linux builds on SD that people are mentioning are only intended as developmental/test installs. The RISC OS build needs the same test status with the next stage of expansion being to simply plug in a USB stick. Presupposing the addition of FatFS32 to the SD image so things aren’t limited to =< 2GB sticks.

I wouldn’t be happy using an SD card for !Boot until we have the option of moving the frequently writable parts of boot elsewhere (Choices, Resources?) for security of data, less wear on the card and speed of writes. Where people have followed the recommendation to keep Messenger’s data files in choices this could have quite an impact on the number of writes to the card, plus Scrap used as cache by printing, browsing and many other functions.

There is already a read only boot for resourcesfs on a stand alone ROM, so couldn’t the same methods be used?

I would like to see the Boot drive able to be set read-only, and just unlocked when changes are needed.

Why make things more complicated.

The idea with having everything on an SD card is to keep everything as simple as possible. Just write the image to an SD card, plug it in and away you go.

Unless you’re emailing, printing and browsing non stop 24 hours how likely is it you’re going to wear out an SD card for typical use cases. Highly unlikely I would imagine.

My BBxM is on 24/7, used for emails, newsgroups, browsing and occasional printing…

Chris, I wouldn’t regard it as unlikely never mind high unlikely. Graham has already given his usage pattern and although for many people the Beagle is a second machine these are just the first machines in a new style. In due course I have no doubt that the only machines people use for RISC OS will be using this style of boot.

I’m downstairs at present but upstairs is a venerable old RPC that handles mail and almost never gets switched off. I’d like to move to new machinery and do much the same without the need to renew the SD card at intervals to cope with high use effects.
Earlier I gave a scenario that only used SD for “temporary” storage when no other resource was available and with a minature format USB that should be pretty much never.
The other advantage of putting the personalised items on the removable drive is that multiple users could use the same machine with total security.

How does leaving a machine on 24hours affect the lifetime of an SD card? Unless you’re running some sort of server that is constantly in use the writes will be minimal. Plus the wear leveling will stop hotspots occurring. I can’t see that there is anything to worry about.

“How does leaving a machine on 24hours affect the lifetime of an SD card? Unless you’re running some sort of server that is constantly in use the writes will be minimal.”

Mail (as noted earlier), and off the top of my head: environmental data logging, home automation.

Or were you just thinking of using the machines for a few legacy apps as a curiosity?
Yes we are in an experimental situation at present, the suggestion was for the future. I did suggest a setup that catered for both and was simple for users.

Mail (as noted earlier), and off the top of my head: environmental data logging, home automation.

Still can’t see that there is anything to worry about with that level of usage on current hardware.

Or were you just thinking of using the machines for a few legacy apps as a curiosity?

The main usage scenario I was thinking of would be an owner of a Raspberry Pi coming across RISC OS for the first time.

For the RPi I can see where you’re coming from Chris, but most of the other boards so far are a bit more blessed in connectivity so there’s no hardship in adding a USB stick or USB-connected HD – as I’ve done. Mine’s got a SATA HD in a USB-SATA/PATA case, USB CD, network-connected printer and USB/DVI KVM mostly connected via a powered 13 port USB hub that also charges my phone! Email/News usage does a lot of writes including debatching, indexing, logging, expiring, etc. Browsing is similar. Disc access is already slower than the Iyonix as it goes via USB, and writing to SD is slower still. You also have to take into account the available capacity in SD cards – does the board accept SD/SDHC/SDXC and what limits does that imply for a working – not experimental – computer?

Why is everyone getting in such a tizz over mythical SD cards which pop their clogs five minutes after running Messenger on them? The SD protocol performs rigorous wear levelling in hardware even if RISC OS hammers the storage. And limitations to the number of writes apply to all flash memory, not just SD cards, very much including USB hard drives!

Looks like a classic case of ignorance and novelty breeding fear to me…

automatically create a RAM disc and place those transient items there? […] see no reason for those retained items not being placed in Choices if they are infrequently written and in a truly transient location if they are frequent (many times per session) writes.

Why not, indeed? It seems unnecessary for the truly transient stuff to do otherwise, provided the size of the RAM disc isn’t an issue. Could there also be potential (minor) performance improvements?

1. What if the app requires a lot of RAM for (ha-ha, hardly likely for the foreseeable future) video editing? The available RAM disc size will be significantly reduced.
2. What happens when the RAM disk becomes full of “ShowsCrap”, especially if the machine is on 24/7?
3. Should old files be automatically deleted?
4. What used to happen when !Scrap was on floppy and it became full?

the wear leveling will stop hotspots occurring

That seems to be the received wisdom from other discussions. And the same goes for the USB flash drives referred to.

I have a tablet which is capable of functioning entirely without extra storage (although this is optional). This seems to all be on one uSD card, unless I’ve misunderstood something… the OS, the storage, the temporary files (assuming Android uses them), everything.

The major concerns are the same ones as ever: data loss and machine settings. On Android I think these are stored in the cloud. And under RISC OS, it’s possible to create backups of both; so even if your SD-based system dies completely, all is not lost.

Why is everyone getting in such a tizz over mythical SD cards

I was just going to ask the same question, seeing as we’ve all been using Beagleboards booting from USB sticks for the past couple of years…! It’s not like SD cards don’t have built-in wear-levelling and USB sticks do. The truth is, if you don’t feel safe hammering (and not much in normal RISC OS use ‘hammers’ the drive*) the SDFS drive, then you need a USB hub and a USB hard disc drive.

• Doing builds is the most intensive disc-bound activity I’ve come across, with email (debatching/indexing) coming in second – neither of these lend themselves to using a RAM disc because they need so much disc space. You can move Scrap into RAMFS but most things I’m aware of don’t really ‘hammer’ Scrap.

But the work has already been done for read only media.

The other good reason for having a read only boot drive is security.

If the bootdrive is properly locked, then users messing with setting etc. is not going to be a problem.