In article <20150505103028.GG19625(a)kyllikki.org&gt;, Vincent Sanders <vince(a)netsurf-browser.org&gt; wrote: I wonder if this is because RISC OS files are 'defragmented' all the time - I think I am correct in saying that when a file becomes too big for the contiguous space it currently occupies, it is copied into a larger block of free space. This means that as the file grows, it may be regularly being copied somewhere else on the disc, and with files that may be hundreds of MB in size, this will be slow - very much so when the drive is an SD card. -- Chris Johnson

In article <20150505103028.GG19625(a)kyllikki.org&gt;, Vincent Sanders <vince(a)netsurf-browser.org&gt; wrote: [snip] OK. VRPC, 4.02, content/llcache.c llcache_finalise 3361: Backing store average bandwidth 15983181 bytes/second Hope that this is useful.

In message <019bfbbe54.Andrew-Pin(a)waitrose.com&gt; on 5 May 2015 Andrew Pinder <Andrew.Pinder(a)tiscali.co.uk&gt; wrote: [snip] I wonder how stable the measurements are. I've just upgraded this ARMini to RO 5.22 so have redone the measurements, still with NS#2771: 161126 bytes/second. That's a massive increase. I had visited a number of websites for that. Trying going to just www.buxtonweather.co.uk (my homepage) as before now gives 154588 bytes/second - only 4% different. Have I missed something, or have ROOL done something spectacular in the changes from 5.20 to 5.22? Regards Andrew -- Andrew Pinder

In article <0c9680c054.Andrew-Pin(a)waitrose.com&gt;, Andrew Pinder <Andrew.Pinder(a)tiscali.co.uk&gt; wrote: Will some of this not be due to the fact that stuff is already in the cache and won't be saved again? -- Chris Johnson

In article <0c9680c054.Andrew-Pin(a)waitrose.com&gt;, [snip] Yes, me too. Seemingly, large variance here too. Kind regards Brian

Vincent Sanders, on 5 May, wrote: [snip] NetSurf #2771 bytes/sec. Lighter sites with presumably less to cache returned 56655 and 44821 bytes/sec, but the "too slow" warning never appeared. On VRPC OS4.39 on Windows 7, 508804, 1033119 and 1119900 bytes/sec which is better than previously. -- David Pitt

OK perhaps I needed to be more explicit in what I wanted to achieve from this testing. I am interested in the persistent disc cache write performance on different platforms, especially RISC OS, to see if my recent changes improve the situation there.. This means the browser must be used to retrieve numerous web pages with lots of cacehable content (images, html, css etc.) and given time to write that data to disc. This usually happens in the background while the user is reading the page they just loaded. It is not useful (or sufficient) to simply load the browser, visit a page and exit. This is explicitly why I asked for help from real users because developers usage data is not representative. So if you participate please do run the browser for a while for your usual browsing session and return the information at the end. The pages you visit, the speed of your connection and the sites you visit have no bearing on the results I am after. As long as the sites data is cacehable in some way it should be sufficient. The information I want is contained in the log file at exit as most of you have discovered. I have improved whats reported with build CI 2774 and would appreciate two lines of output which appear all together near the end of the log. An example is: content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2620/240/2380/0 (100%/9%/90%/0%) content/llcache.c llcache_finalise 3361: Backing store wrote 96531600 bytes in 6617 ms average 14626000 bytes/second This example shows 96 Megabytes of data written in 6.6 seconds yielding the 14 Megabytes a second rate from a long browsing session Note that data was written over a couple of hours the time here refers to the actual the browser had to wait for the OS to complete the write operation. I would like these two lines from the logfile along with the OS and hardware spec of the system. E.g. "RISC OS 5 on Iyonix with FAT formatted hard drive" or "ROOL beta on Raspberry Pi 2 with FAT formatted SD card" If your cache is being effective you may notice that subsequent runs of the browser have quite varying write rates which can be caused by not writing enough data to get a sensible average. Unless the cache has written at least 250 kilobytes of data the results are not useful. For example if your cache has only written a hundred bytes of data the time it takes to do that will hugely affect the write rate. This is the cause of several "false positives" on the "write rate too slow" previously because a write of a hundred bytes that took a millisecond was considered as "too slow" instead of a rounding error! -- Regards Vincent http://www.kyllikki.org/

In message <ac1710c154.Andrew-Pin(a)waitrose.com&gt; on 9 May 2015 Andrew Pinder <Andrew.Pinder(a)tiscali.co.uk&gt; wrote: After a subsequent lengthy but intermittent session I eventually got the bandwidth warning so then quit and got: (17974.940000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 563/78/485/0 (100%/13%/86%/0%) (17990.750000) content/llcache.c llcache_finalise 3361: Backing store wrote 1222126 bytes in 0 ms average 9334 bytes/second Regards Andrew -- Andrew Pinder

In message <20150508154706.GB2480(a)kyllikki.org&gt; Vincent Sanders <vince(a)netsurf-browser.org&gt; wrote: Iyonix, RISC OS 5.22, 38 GiB spinning rust, Filecore formatted. NS 2774. Dave ____________________________________________________________ Can't remember your password? Do you need a strong and secure password? Use Password manager! It stores your passwords & protects your account. Check it out at http://mysecurelogon.com/password-manager