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/
