!Store sale starts Jan 1st
Chris Evans (457) 1614 posts |
re: lazy page mapping Would running it twice cause all the pages used to be mapped appropriately on the rerun? Edit just seen Colin’s reply along similar lines. |
Jon Abbott (1421) 2608 posts |
To avoid Lazy Page Mapping, you want something along the lines of:
|
Chris Johnson (125) 819 posts |
I have had trouble reproducing this. What sync were you doing? Was Fat32FS the FS for both primary and secondary? Were you multitasking or single tasking? I have tried some synching from SCSI to Fat32Fs and the process completed without pain. The only time I did get pain was syncing a directory that included the update of a particular zip file, which caused the Filer_Action window to display an error box. The log contained one entry in DDEUtils, followed by three in an unknown location (last app : Filer_Action). If SparkFS is killed before doing the sync, then these four entries disappear, and there is no zero pain log at all. I’ll ring a few more changes and see what happens. |
David Pitt (102) 743 posts |
The backup was SCSI to Fat32 and single tasking. Multitasking seems OK. //->Syncjob // Produced by SyncDiscs at 3:17pm 13 Jan 16 // // Primary SCSI::HardDisc4.$.Info Secondary Fat32fs::8GBpen.$.__BU.Pen16a.test Scrap LogFile <SyncDiscs$Dir>.^.Log Newer 0 Extra 0 Log 0 Overwrite 0 MultiTask 0 NewLog 0 NumberOfLogs 5 AutoOpenLog 0 FastCopy 1 TimeEqual 1 TimeRes 300 MultipleFA 0 MultipleFANum 10 IgnoreFiletype 0 Compare 0 LogInPrimary 0 VerboseLog 0 |
Jeffrey Lee (213) 6046 posts |
Some observations on the RISCOSMark results that people have been getting. It looks like the Pi 2 needs a little bit of time to “warm up” at startup. If I run RISCOSMark right after startup then I get low results for the memory test (about 3-4 times lower than normal). If I then run it again, or if I reboot and wait about 20 seconds before running it, then I get results which are in line with those reported by David (counter in the 8500 range). The behaviour is the same whether the CPU is forced to 900MHz or not (although it seems to be a lot easier to reproduce with force_turbo off – faster clock speed means it “warms up” faster?). This is with firmware from 15th July 2015 and a self-built high vector ROM from the 8th of Jan. The Pi 1 doesn’t seem to suffer from this issue – all results are the same (testing using the same SD card – with force_turbo off). Lazy task swapping shouldn’t be an issue since the test runs thousands of times (that’s what the number is). Also it’s worth noting that the memory test operates on a 128K block of memory (copying it from one location to another) – so for anything post-Iyonix it’s more of a cache performance test than a memory performance test. |
Rick Murray (539) 13422 posts |
??? Even back in the Windows 3.11 days, benchmarking software there used different sized blocks ranging from 4KiB to 4MiB. Perhaps to counter this issue and show real memory speeds beyond what typical caching would mask? |
Chris Hall (132) 3510 posts |
The newer firmware for the Pi defaults to a low speed and expects the OS to kick it to a higher speed when necessary. RISC OS cannot yet do that on the Pi and so for the Pi Zero (where I have had to use the latest firmware) I have used force_turbo=1 with explicitly set clock speeds to make sure it runs at its rated (1000MHz) speed. |
George T. Greenfield (154) 718 posts |
That would seem to be the case with the Pi2 also: mine’s firmware is dated Feb 2015 and, until I explicitly set the component frequencies in Config.txt, was running by default at an estimated 500-600MHz (based on both benchmarks and actual task completion times). (FWIW I’m using cpu-core-ram settings of 900-250-450, which appear to be the standard maximums for the Pi2) |
Chris Johnson (125) 819 posts |
This is a bit of a nightmare!
I have carried out some scsi to fat32fs syncs in single tasking mode, and have not yet generated any zero pain logs. Guess I’ll just have to persevere. |
David Pitt (102) 743 posts |
Off topic stuff deleted. |
Andrew Rawnsley (492) 1415 posts |
I just wonder… is there any way a moderator/admin could please split this thread into another and move it out of annoucements? There’s “going off topic”, and then there’s this thread which was basically hijacked at gunpoint by men in masks! I am purposefully very careful of what I post in Annoucements (you’ll note I don’t do R-Comp press releases etc) except for things |
Steve Pampling (1551) 7952 posts |
One of those things I suppose. I rather expected an answer to the second post in the thread. In the absence of that answer people offered solutions, workarounds and a bit of drift occurred. BTW. Is there an answer to the question Fred asked? I may have missed it in the drift. |
David Feugey (2125) 2687 posts |
I agree. Both subjects are very interesting, but of topic is of topic. I hope to see more 32bit ready / AEmulor ready packages from RComp. Desktop Suite and Wimp Suite are really a good surprise for me. Bunch of tools. |
Frederick Bambrough (1372) 825 posts |
Crumbs! Did I ask a question? Seems so long ago :→ Fortunately it’s Messenger Pro on the Mac that keeps me going, though that now seems to be a dead product. While here, thanks for the updated ZP module Rick. |
Andrew Rawnsley (492) 1415 posts |
Mpro Win/Lin/Mac is still live – last update was mid-2015. You can get the latest download from http://www.intellegit.com/download |
Frederick Bambrough (1372) 825 posts |
I’m aware of that Andrew. 9th March. Have you had a look at the Mantis bug tracker and compared it with the actual development over the last couple of years? It’s not progress, is it. I’m sure a paid for update with some real progress wouldn’t cause outrage. |