!Store sale starts Jan 1st

I’m also in High Vector land on a Pi2, courtesy of Chris Hall’s helpful advice on the previous page of this thread re latest firmware, and the 11 Jan 16 ROM build. Somewhat to my surprise, most of my extensive list of apps still works (see below), but the showstoppers, from the point of view of a workable system, are:
!Printers; !LanMan98 v2.04; !PDF; !Photodesk v3.12; !SyncDiscs; !Thump v1.51 (which ran but failed to render a JPEG); !NetFetch v2.20 (long overdue for updating anyway, probably).
One oddity: !ROmark v1.01 ran (remarkably, considering its vintage), and showed a memory speed roughly 1/3 as fast as the RC14 value – all other stats were similar: is this an expected consequence of the move to High Vector positioning?
The following apps have /not/ been tested rigorously but all loaded to the icon bar and opened an app ‘window’ or a sample file:
!Alarm v2.89
!Artworks v2 X 2.00
!Calibre v3.23
!ChangeFSI v1.46
!CloneDisc
!Closefiles v1.03
!CloseUp v3.18
!DiscKnight v1.51
!DPScan v1.25
!Draw v1.28
!DrawPrint v1.40
!Edit v1.73
!Fireworks v1.34/05
!GView v1.52
!GraphDraw v2.68
!Help v3.22
!Multiplot v2.23
!NetSurf v3.4 CI#3250
!Otter browser v09.9
!Ovation Pro v2.77y
!PackMan v0.83
!Paint v2.20
!Rhapsody32 v4.31
!ROmark v1.01
!Spark v1.43
!StrongEd v4.69b5 (David, please note!)
!SwiftJPEG v1.12
!SystemDisc
!Techwriter v9.12
!Usage v1.02
!Variations v0.41d
If Printers, LanMan98 (or a substitute), NetFetch, PDF and SyncDiscs could be got to work, I could consider migrating permanently. As things stand, without ZeroPain, I can’t, and there I think is the rub re testing on an extended scale.

Addendum: !MessengerPro v7.08 also works as before, as does !Otter.

but the showstoppers, from the point of view of a workable system, are: !Printers; !LanMan98 v2.04; !PDF; !Photodesk v3.12; !SyncDiscs; !Thump v1.51 (which ran but failed to render a JPEG); !NetFetch v2.20

Printers – So far I haven’t seen any pain from 1.83 but !PS3 1.21 does go wrong. There is no actual printer connected to the Pi, all printing is to PDF.

LanMan98 – Version 2.06 should be released soon, I have seen it said that ROOL’s LanManFS has now caught up.

SyncDisc fails here with Fat32FS but is OK with SCSI, not very thoroughly tested it has to be said.

Thump 1.53 is here – which doesn’t help, it pains.

NetFetch/Hermes – A Zero Page clean version is pending. The recently fixed POPstar is in use here.

StrongED – The developer as ever is in front of the game and the issues are fixed in the sources, a release will turn up at some point.

When I tested SyncDiscs a while back I thought I had fixed a couple of issues and it was ok. I will have another look at it on the PandaBoard (the only machine that is running a zero pain OS at the moment).

It would be useful if any zero pain logs implicating SyncDiscs could be sent to me (chris at chrisjohnson dot plus dot com). I have been having a play and a number of compares and actual syncs progressed and completed without any pain. However, I did provoke a small number of zero pain logs under certain conditions that caused Filer_Action to display a warning box. The location appears to be in the filer_action module rather than SyncDiscs itself. I will be investigating further. I haven’t tried using Fat32FS yet, only SCSI and ShareFS.

The location appears to be in the filer_action module rather than SyncDiscs itself.

Filer and Filer_Action have numerous places where input parameters are not checked. Since these routines usually tend to be accessed via the GUI which greys out strange actions – like calling for the help on an application (or group of apps) without selecting an application directory icon by simply having F1 do the call – people don’t notice.

It would be useful if any zero pain logs implicating SyncDiscs could be sent to me

Syncing to Fat32 Pain log sent.

Syncing to Fat32 Pain log sent.

Hasn’t arrived here yet. Other mail has been coming in to that particular email address.

Hasn’t arrived here yet.

Should have now. It was stuck in the outbox here, brain pain. Sorry.

Received now OK. Thanks

Addendum 2: the !Printers version that failed to load under HVP was 1.81.
My comment about 1/3 speed memory seems to have escaped notice, but it seems to me that if this is a genuine reading, the implication for HVP OS versions is not trivial. !Firebench (which also ran successfully) gave a result about 100 frames/sec (10%) lower than expected.

My comment about 1/3 speed memory seems to have escaped notice, but it seems to me that if this is a genuine reading, the implication for HVP OS versions is not trivial. !Firebench (which also ran successfully) gave a result about 100 frames/sec (10%) lower than expected.

I noticed it, but didn’t respond to it, because I don’t know the answer (and didn’t find the time to look into it last night).

I wouldn’t expect changing to high processor vectors to have any significant effect on performance, and there are a great many things that will have changed between RC14 ROM + firmware and latest ROM + firmware, so more investigation is needed before people start trying to pin the blame on specific changes.

so more investigation is needed before people start trying to pin the blame on specific changes.

Easy test for the nerdically inclined.
Build the latest ROM. Twice. High and low vectors. Run the same test on each. That’ll say whether the slow down is HVP or something else.

In the grand scheme of things it’s probably not worth spending time and energy on it. However, I thought I’d try a simple test – the latest firmware with RC14 – to see if I could reproduce the ‘slow memory’ effect. Unfortunately RC14 won’t boot in that case: you get a technicolour square, but no display.

slow memory effect

Just guessing but it may be portable_idle/speed slowing down the processor when it thinks it’s doing nothing. Does it actually feel slower in use?

My comment about 1/3 speed memory seems to have escaped notice

Remark from a Mk2 Raspberry explicitly clocked at 900MHz, OS5.23 (6Jan16) v rc14. It’s spot the difference time.

force_turbo=1
arm_freq=900
core_freq=450
sdram_freq=450


RISCOSmark 1.01 (14 May 2003)
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)
BCM2835 processor &2 type &0 revision &6
Filing system: SCSI - CSD not set
Graphics Resoloution: 1680x1050,16M colours

Tested at Tue,12 Jan 2016.10:35:02
Machine type HAL
MOS Utilities                                        OS5.23     OS5.21 (rc14)
                                              (06 Jan 2016)     (07 Feb 2015)
                                                High Vector

Test                                           Benchmark       Benchmark
Processor - Looped instructions (cache)      1039432   584%    1020125   573%
Memory - Multiple register transfer             8596  5306%       8487  5238%
Rectangle Copy - Graphics acceleration test     1322   546%       1373   567%
Icon Plotting - 16 colour sprite with mask     19670   983%      17292   864%
Draw Path - Stroke narrow line                  4969   318%       4709   301%
Draw Fill - Plot filled shape                   6556   449%       4692   321%
HD Read - Block load 1MB file                  20877   700%      18249   611%
HD Write - Block save 1MB file                 16900   555%      11484   377%
FS Read - Byte stream file in                    266   128%        165    79%
FS Write - Byte stream file out                  159    82%        128    66%
<pre>
  

David is it really “Memory – Multiple register transfer 8596 5306% 8487 238%”
The absolute figures are only about 1% different.

So RISCOSmark is getting it wrong somewhere!

David is it really “Memory – Multiple register transfer 8596 5306% 8487 238%”

Sorry pardon, editing error, trying to narrow the columns. It should be :-
“Memory – Multiple register transfer 8596 5306% 8487 5238%”.
Now corrected.

So RISCOSmark is getting it wrong somewhere!

No need, I can do that for myself.

Addendum 2: the !Printers version that failed to load under HVP was 1.81.

Is the RemPrnSpt module version 1.15?

Easy test for the nerdically inclined.

As luck has it I had high and low vector builds of 20Dec15 preserved in case of 2016 ZeroPain Armageddon. I romarked them both and was surprised to find the low vector version was going at about half the speed of its high vector partner. As ever here this was user error, ‘force_turbo’ was set to zero for the low vector run. Setting it to ‘1’ so that the Mk2 Pi really was running at 900Mz sorted that out and the results were then similar. That would imply that left to it own devices the Mk2 Pi was running at about 450MHz, and if that is true then how is that value arrived at. My guess is that if not explicitly set then under RISC OS the Mk2 Pi’s clock frequency may be undefined, or at least not by us, and may it is that that explains the reported romark differences.

The results below show some difference, especially the Memory result, between the high and low vector builds. The builds are not exactly like for like. The high vector build is ROOL’s. My low vector build was two days later but there were no changes in cvs. A more rigorous test would be high and low versions built from exactly the same source and both built with the same process, both built here that is. But that can wait, lunchtime looms!

force_turbo=1
arm_freq=900
core_freq=450
sdram_freq=450

bootcode.bin  09Sep15
fixup.dat     08Dec15
start.elf       ""

RISCOSmark 1.01 (14 May 2003)
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

Tested at Tue,12 Jan 2016.11:15:34
Machine type HAL
MOS Utilities 5.23 (01 Dec 2015)
FX0 RISC OS 5.23 (20 Dec 2015)
BCM2835 processor &2 type &0 revision &6
Filing system: SCSI - CSD not set
Graphics Resoloution: 1680x1050,16M colours

                                                 High Vectors         Low Vectors
Test                                             Benchmark            Benchmark
Processor - Looped instructions (cache)          1044572   587%       962493   541%
Memory - Multiple register transfer                 8547  5275%         3821  2358%
Rectangle Copy - Graphics acceleration test         1267   523%         1434   592%
Icon Plotting - 16 colour sprite with mask         19408   970%        16024   801%
Draw Path - Stroke narrow line                      4959   317%         3664   234%
Draw Fill - Plot filled shape                       6466   443%         4013   275%
HD Read - Block load 1MB file                      20877   700%        14769   495%
HD Write - Block save 1MB file                     15906   523%        15058   495%
FS Read - Byte stream file in                        252   121%          101    48%
FS Write - Byte stream file out                      150    78%           94    48%

@David: RemPrnSpt = 1.13

Re your ‘explicitly-clocked Pi2’ Config settings: force_turbo=1; arm_freq=900; core_freq=450; sdram_freq=450, I’ve just tried them: it’s added about 40% to the speed (Firebench: 1446 frames/sec vs. 920 fr/sec; standard Greenfield graphics test* 30secs vs. 42secs), all of which lends support to your theory that, without explicit settings, the Pi2 runs at sub-optimal clock speeds under RISC OS. For comparison, a Pi B explicitly clocked at 900MHz does 1206 fr/sec in Firebench, and completes the graphics test in 37 secs, giving the Pi2 a 20-25% edge, clock for clock, which is what I would expect given the more advanced architecture: but is it safe??

[*12 x c5MB Jpegs slideshowed in Thump 1.51, best dither, fit screen, step time = 0secs]

A more rigorous test would be high and low versions built from exactly the same source

Which I have now done. Low and high vector self builds and ROOL’s download Pi ROMs perform all but identically, excepting for some disc speed variance, the FS Read and Write drop to about half on the low build.

What is odd is that all three of those builds return a ‘Memory’ result less than the previous ROM. This has been double and treble checked and does seem to be a real effect.

RISC OS 5.23 (09 Jan 2016)
Processor - Looped instructions (cache) 1044557     587%
Memory - Multiple register transfer        8595    5305%

RISC OS 5.23 (12 Jan 2016)
Processor - Looped instructions (cache) 1050248     590%
Memory - Multiple register transfer        5093    3143%

What is odd is that all three of those builds return a ‘Memory’ result less than the previous ROM.

It may be the effect of lazy page mapping which triggers the Abort handler, try touching all memory pages prior to running the benchmark to see if there’s a difference.

It may be the effect of lazy page mapping which triggers the Abort handler

That sounds plausible. Another ‘romark’ foible was that on inserting lines to give more machine information the ‘Memory’ result altered dramatically.

try touching all memory pages

If only I knew how…. My understanding of the low level internals is just that, low level.

Anyway it is probable that the ‘Memory’ test in not simply measuring raw memory performance and as such it is not a meaningful comparison. I shall ignore it for now.

Just clear the memory romark uses for the memory test before it does the memory test that will ensure the memory is paged in.

Edit:

Or perhaps easier, make it run the memory test part twice on the same block of memory