On Tue, Mar 31, 2015 at 03:44:06PM +0100, Jim Nagel wrote:
> These pages from local newspaper takes ages in the fetching-processing
> stage, and then finally displays its text in a pane that is too narrow
> to read.
> http://www.centralsomersetgazette.co.uk/Just-doctor-ordered/story-26229361-deta
I know several RISC OS users regularly use the CI builds and have had
issues with the disc cache. This is partly a request for assistance
and partly a warning.
I have recently changed the disc based caching to use fewer small
files. This change is not backwards compatible and will leave the old
ca
In article <20150403111441.gb18...@kyllikki.org>,
Vincent Sanders wrote:
> (2298.804881) content/llcache.c llcache_finalise 3352: Backing
> store average bandwidth 128324035 bytes/second
Hells bells - you'll be lucky to a tenth of that speed on RISC OS
hardware and probably less on usb or sdfs
I can see why RISC OS gets indigestion with the cache. Have just
deleted the cache on the Iyonix, and there were over 21,000
directories and over 19,000 files.
--
Chris Johnson
In article <20150403111441.gb18...@kyllikki.org>,
Vincent Sanders wrote:
> The bandwidth line will be about 20 lines from the end of the log
I restarted Netsurf with cache enabled on the Iyonix. Loaded up the
ROOL forum. Message came up almost immediately that the cache was
being disabled.
Qu
Vincent Sanders wrote on 3 Apr:
> If you are feeling very adventurous you can report the bandwidth
> achieved. This is a line in the debug Log file held in scrap *after*
> the browser has been quit. The last line of the Log will read
> something like:
> (2298.806358) desktop/netsurf.c netsurf_exi
Vincent Sanders, on 3 Apr, wrote:
[snip - cache bandwidth]
NetSurf 2696
RPi2 SDFS 6067 bytes/s
RPi2 Fat32FS 15220 bytes/s
Iyonix320252 bytes/s
A9home509265 bytes/s
VRPC W7 SSD 605771 bytes/s
--
David Pitt
On Fri, Apr 03, 2015 at 12:48:39PM +0100, Jim Nagel wrote:
> Vincent Sanders wrote on 3 Apr:
> > If you are feeling very adventurous you can report the bandwidth
> > achieved. This is a line in the debug Log file held in scrap *after*
> > the browser has been quit. The last line of the Log will re
In article <54ae82a927ch...@chris-johnson.org.uk>,
cj wrote:
> I can see why RISC OS gets indigestion with the cache. Have just
> deleted the cache on the Iyonix, and there were over 21,000
> directories and over 19,000 files.
Yes, there seem to be lots of directories - many empty. The non-emp
cj, on 3 Apr, wrote:
> In article <20150403111441.gb18...@kyllikki.org>,
>Vincent Sanders wrote:
> > The bandwidth line will be about 20 lines from the end of the log
>
> I restarted Netsurf with cache enabled on the Iyonix. Loaded up the ROOL
> forum. Message came up almost immediately that
On 31 March 2015 at 16:44, Jim Nagel wrote:
> These pages from local newspaper takes ages in the fetching-processing
> stage, and then finally displays its text in a pane that is too narrow
> to read.
> http://www.centralsomersetgazette.co.uk/Just-doctor-ordered/story-26229361-detail/story.html
>
On Fri, Apr 03, 2015 at 01:30:14PM +0100, nets...@avisoft.f9.co.uk wrote:
> In article <54ae82a927ch...@chris-johnson.org.uk>,
>cj wrote:
> > I can see why RISC OS gets indigestion with the cache. Have just
> > deleted the cache on the Iyonix, and there were over 21,000
> > directories and ove
In article ,
David Pitt wrote:
> Hmm! My Iyonix did over three time better than that, and there was
> no "too slow" message. My test piece was http://www.dailymail.co.uk
> because that is a particularly heavy duty site.
OK. A lot of random browsing around that site led to:
(5743.13) cont
In article <20150403131050.gq29...@platypus.pepperfish.net>,
Rob Kendrick wrote:
> On Fri, Apr 03, 2015 at 01:30:14PM +0100, nets...@avisoft.f9.co.uk wrote:
> > In article <54ae82a927ch...@chris-johnson.org.uk>,
> >cj wrote:
> > > I can see why RISC OS gets indigestion with the cache. Have
On Fri, Apr 03, 2015 at 02:39:05PM +0100, cj wrote:
> In article ,
>David Pitt wrote:
> > Hmm! My Iyonix did over three time better than that, and there was
> > no "too slow" message. My test piece was http://www.dailymail.co.uk
> > because that is a particularly heavy duty site.
>
> OK. A l
> > >
> > > I suspect much of the delay for small files is due to checking,
> > > creating, and traversing directories!
>
> > The depth was chosen so it would work on poor-quality file systems that
> > only allow a handful of entries in a directory, such as FileCore :)
>
> It is a shame that
cj, on 3 Apr, wrote:
> In article ,
>David Pitt wrote:
> > Hmm! My Iyonix did over three time better than that, and there was no
> > "too slow" message. My test piece was http://www.dailymail.co.uk because
> > that is a particularly heavy duty site.
>
> OK. A lot of random browsing around th
"J. F. Lemaire", on 3 Apr, wrote:
> On 31 March 2015 at 16:44, Jim Nagel wrote:
> > These pages from local newspaper takes ages in the fetching-processing
> > stage, and then finally displays its text in a pane that is too narrow
> > to read.
> >
http://www.centralsomersetgazette.co.uk/Just-docto
I have now tried on the PandaBoard. Used random pages from the Daily
Mail site (not much content if you are not interested in celebrates!).
The first time I tried I fairly quickly ended up with the cache being
disabled - the logged average speed was not much over 100 KB/s.
However, I then reran N
On Fri, Apr 03, 2015 at 03:13:17PM +0100, David Pitt wrote:
> I also think NetSurf's performance is severely hampered by the slow
> processors available to RISC OS.
No, the CPUs are perfectly adequately fast. A Raspberry Pi can do many
megabytes a second when running Linux. RISC OS's IO layer an
In article ,
David Pitt wrote:
> Can't say that I blame it! The ROOL forum content is particularly
> turgid at the moment, no sensible software would see any purpose in
> cacheing that.
>
I am not sure what you mean there. Viewing the forum on an old
(ex-XP) laptop now running a light linux,
In article <20150403111441.gb18...@kyllikki.org>,
Vincent Sanders wrote:
> If you are feeling very adventurous you can report the bandwidth
> achieved. This is a line in the debug Log file held in scrap *after*
> the browser has been quit. The last line of the Log will read
> something like:
>
22 matches
Mail list logo
