Re: Disc cache worth it?
In message <20140624211245.gm1...@platypus.pepperfish.net> Rob Kendrick wrote: > On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote: >> >> It would be interesting to see if a Raspberry Pi running the GTK >> version from SD card has the same slowness. > > Assuming you were running it on one of the flavours of UNIX available > for it (Linux, NetBSD), then no. > > These operating systems receive the write requests from applications and > queue them for writing to underlying block devices in the background, > while other apps sit there waiting for input or idling. Under RISC OS, > file system writes stop /everthing/ until they complete. > [snip] Does that mean that selecting 'Make file operations multitask' in !Configure-Filer, actually doesn't? -- George
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 12:14:16PM +0100, george greenfield wrote: > In message <20140624211245.gm1...@platypus.pepperfish.net> > Rob Kendrick wrote: > > > On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote: > >> > >> It would be interesting to see if a Raspberry Pi running the GTK > >> version from SD card has the same slowness. > > > > Assuming you were running it on one of the flavours of UNIX available > > for it (Linux, NetBSD), then no. > > > > These operating systems receive the write requests from applications and > > queue them for writing to underlying block devices in the background, > > while other apps sit there waiting for input or idling. Under RISC OS, > > file system writes stop /everthing/ until they complete. > > Does that mean that selecting 'Make file operations multitask' in > !Configure-Filer, actually doesn't? It means that it writes smaller chunks and calls Wimp_Poll in between them to give other applications a chance, at the expense of expediency. The whole system stops while the individual chunks are written, being accepted by FileSwitch, which then in turn passes them to the handling file system (most likely FileCore), which then hands them to the block device driver (ADFS, IDEFS, SDFS, etc), percolating the success/failure result back up the stack to the application. On other operating systems (UNIX, Windows, BeOS, AmigaOS, OS X), the equivalent of FileSwitch passes the request onto the file system which then writes the data through a buffering system and thus can return almost straight away, while a background process in the kernel then flushes the buffer to the block device while the system is not busy, or a timeout expires. During this process, reads are satisfied through the buffer because they've not yet reached the block device. There is some functionality in Vince's disc cache work to allow for something similar to the "file operations multitask" option, and may need tuning. As he said, this is an experimental feature and the feedback that has been happening does have some value. B.
Re: Disc cache worth it?
On 2014-06-25 12:57, Rob Kendrick wrote: On Wed, Jun 25, 2014 at 12:14:16PM +0100, george greenfield wrote: Does that mean that selecting 'Make file operations multitask' in !Configure-Filer, actually doesn't? It means that it writes smaller chunks and calls Wimp_Poll in between them to give other applications a chance, at the expense of expediency. The whole system stops while the individual chunks are written, being accepted by FileSwitch, which then in turn passes them to the handling file system (most likely FileCore), which then hands them to the block device driver (ADFS, IDEFS, SDFS, etc), percolating the success/failure result back up the stack to the application. I think there are a couple of errors in that explanation. First of all, IIRC ticking that option only affects FilerAction. This is a desktop facility for doing multitasking operations on files and directories (such as copy, move, delete, etc) with a window opening to show progress. Unticking that option causes these operations to revert to using the single-tasking command line equivalents for these operations (e.g. *copy) which could end up being faster at the expense that your desktop stops multitasking. Secondly, it's not true to say file system operations block everything in RISC OS - some file systems (notably ADFS) implement "background transfers" which allow much of RISC OS to continue to operate while the underlying file operation runs (e.g. via DMA or some such). However, many file systems _don't_ implement background transfers - e.g. SDFS - so these will hog the system for the duration of the low-level operation. Adding background transfers to SDFS has always been on the roadmap but it's a lot of work; implementing background transfers on RISC OS is a particularly tricky task and SDFS is complex enough already for various reasons. It is hoped that one of the later stages of "filesystem improvements" that we've been hosting bounties about on the ROOL site will address some of these issues, but at the current rate that the bounty scheme has been gathering donations, we'll all be dead and gone before any of that work happens. Ta, Steve
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 01:32:58PM +0100, Steve (plusnet) wrote: > Secondly, it's not true to say file system operations block everything > in RISC OS - some file systems (notably ADFS) implement "background > transfers" which allow much of RISC OS to continue to operate while the > underlying file operation runs (e.g. via DMA or some such). However, > many > file systems _don't_ implement background transfers - e.g. SDFS - so > these will hog the system for the duration of the low-level operation. But even with background transfers, the Wimp will typically not continue, no? My understanding is that OS_File SWIs that write data only return when the data is written, and thus the application cannot call Wimp_Poll to allow multitasking to continue - and even if you're using UnixLib threads this doesn't help you because threading does not continue over such SWIs. (Getting into the technical distinctions between WIMP and non-WIMP tasks was something I was trying to avoid getting into on the user's mailing list :) B.
Re: Disc cache worth it?
On 2014-06-25 13:36, Rob Kendrick wrote: (Getting into the technical distinctions between WIMP and non-WIMP tasks was something I was trying to avoid getting into on the user's mailing list :) Fair enough, but if you're going to say things like "the whole system stops while the individual chunks are written" and "Under RISC OS, file system writes stop /everthing/ until they complete" you can't expect me to just sit by and say nothing... ;) Steve
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 01:44:01PM +0100, Steve (plusnet) wrote: > On 2014-06-25 13:36, Rob Kendrick wrote: > >(Getting into the technical distinctions between WIMP and non-WIMP > >tasks > >was something I was trying to avoid getting into on the user's > >mailing > >list :) > > Fair enough, but if you're going to say things like "the whole system > stops while the individual chunks are written" and "Under RISC OS, > file system writes stop /everthing/ until they complete" you can't > expect > me to just sit by and say nothing... Of course not :) But from the user's point of view, everything does stop :) B.
Re: Disc cache worth it?
On 2014-06-25 13:51, Rob Kendrick wrote: Of course not :) But from the user's point of view, everything does stop :) Pesky users... :) Steve
Re: Disc cache worth it?
On 25 Jun at 13:32, "Steve (plusnet)" wrote: > It is hoped that one of the later stages of "filesystem improvements" > that we've been hosting bounties about on the ROOL site will address > some of these issues, but at the current rate that the bounty scheme > has been gathering donations, we'll all be dead and gone before any of > that work happens. I have intermittently subscribed to a bounty or two. I wonder if the ROOL systems could improve the volume of subscriptions received: 1. By issuing a public report occasionally (yearly? And to csaa?) on what has been achieved and what could do with more funding. 2. When a Bounty has been fulfilled, write to the subscribers to tell them of this good news and invite them to subscribe to other bounties instead, even including with this a list of priorities for RISC OS. 3. Consider changing some aspects of ROOL to a charity, certainly including the Bounty aspect. This would enable the trustees to reclaim income tax paid by the bounty donors. Further the donors who pay higher rate tax could deduct their subscription from the higher rate income, thereby reducing their higher rate tax; if they felt so minded they could then increase their donation by the amount of this higher rate tax relief. That said, how much do you think is needed in the relevant bounty (which?) to encourage a developer to start work? -- Tim Powys-Lybbe t...@powys.org for a miscellany of bygones: http://powys.org/
Re: Disc cache worth it?
On 2014-06-25 14:57, Tim Powys-Lybbe wrote: I have intermittently subscribed to a bounty or two. Rather than hijack this mailing list, you'd be welcome to post these questions to the ROOL bounty forum: https://www.riscosopen.org/forum/forums/8 Cheers, Steve
Re: Disc cache worth it?
On 25 Jun at 15:22, "Steve (plusnet)" wrote: > On 2014-06-25 14:57, Tim Powys-Lybbe wrote: > > I have intermittently subscribed to a bounty or two. > > Rather than hijack this mailing list, you'd be welcome to post these > questions to the ROOL bounty forum: > > https://www.riscosopen.org/forum/forums/8 Can't stand forums. Too much hassle to find the site and the discussion. Mailing lists and usenet are so much easier: the discussion just appears on MessengerPro. I take it that you are not interested in following up your comments on bounties, to which I was merely replying? -- Tim Powys-Lybbe t...@powys.org for a miscellany of bygones: http://powys.org/
Re: Disc cache worth it?
In article , Tim Powys-Lybbe wrote: > > Rather than hijack this mailing list, you'd be welcome to post these > > questions to the ROOL bounty forum: > > > > https://www.riscosopen.org/forum/forums/8 > Can't stand forums. Rather than attempt to get Tim to grapple with his personal demons, I have taken the liberty of posting his suggestions myself so that they might reach a better target audience. Didn't take long, as he'd already done most of the necessary typing! John -- | John Williams | joh...@ukgateway.net Names for Soul Band:- Soul Beneficiary *
