🚀 go-pugleaf

In article <1992Dec18.113330@informatik.uni-kl.de>
m_sattle@informatik.uni-kl.de (Matthias Sattler) writes:
>What are adfsbuffers really good for?

>They should speed up the (hard)disc access but in fact they don't.
>I tried many different tests (hd-speed tests, compiling c programs, ...)
>on the harddisc of my A540 (RO2) with adfsbuffers 0 and adfsbuffers 256k.
>EVERY test with adfsbuffers configured was slightly slower than the test
>without adfsbuffers.
>Hmmmmmm... funny isn't it?

Well, it's interesting that you should say that, but it doesn't concur
with my experience on an A5000. With ADFSbuffers set to 16 as in the
supplied configuration I found that Acorn DTP fell over at the slightest
excuse, particularly if you gave it anything difficult to do or didn't
give it all the available gigabytes before you started. The cure for this
was to set ADFSbuffers to 0.

Having done this I noticed that the desktop appeared to be much slower
and there was much more hard disk activity while it was redrawing windows,
particularly !Draw windows with a lot of text using disk-held fonts.

Richard

In article <1gsjlvINN6p1@bnsgd245.bnr.co.uk>, rap@nnsgs50.tcom.stc.co.uk (Richard Porter) writes:
[bits removed] 
> Well, it's interesting that you should say that, but it doesn't concur
> with my experience on an A5000. With ADFSbuffers set to 16 as in the
> supplied configuration I found that Acorn DTP fell over at the slightest
> excuse, particularly if you gave it anything difficult to do or didn't
> give it all the available gigabytes before you started. The cure for this
> was to set ADFSbuffers to 0.

   One assumes that you have patched Acorn DTP with the patch files supplied
on the support disc for RO3.1?

   It seems quite likely that failing to do this would result in the
instability you describe.

   And thinking along other lines someone on the net a little while ago was
bemoaning the loss of the international keyboard drivers that RO2 had. Again
I wonder if they have tried the IntKey module which claims to restore this
functionality to RO3 for those who need it. I can't say I have tried it much
myself but I assume it does what it is described to do.

   Come on people read the documentation...

Philip

m_sattle@informatik.uni-kl.de (Matthias Sattler) writes:

>What are adfsbuffers really good for?

>They should speed up the (hard)disc access but in fact they don't.
>I tried many different tests (hd-speed tests, compiling c programs, ...)
>on the harddisc of my A540 (RO2) with adfsbuffers 0 and adfsbuffers 256k.
>EVERY test with adfsbuffers configured was slightly slower than the test
>without adfsbuffers.
>Hmmmmmm... funny isn't it?

Nope... not really... if you read the manual/help info on adfsbuffers, it states
that it sets the "number of 1024 byte buffers" used by ADFS. That is, I
get the impression that setting a large value for ADFSBuffers will NOT
have ANY effect on a SINGLE file, but using (e.g.) 256 buffers will allow
up to 256 files to be buffered simultaneously.
A value like 8 or 16 will probably be plenty - this will allow pretty much
all the files you ca expect to be open at any time to be buffered.

As you may now see, the true test of how well ADFS buffers works is to open
lots of files for read/writing, and see how different ADFS buffers values
affect this sort of operation...

-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)

In article <1992Dec18.113330@informatik.uni-kl.de>,
m_sattle@informatik.uni-kl.de (Matthias Sattler) writes:
> What are adfsbuffers really good for?

They speed up ADFS random file accesses.
 
> They should speed up the (hard)disc access but in fact they don't.
> I tried many different tests (hd-speed tests, compiling c programs, ...)
> on the harddisc of my A540 (RO2) with adfsbuffers 0 and adfsbuffers 256k.
> EVERY test with adfsbuffers configured was slightly slower than the test
> without adfsbuffers.
> Hmmmmmm... funny isn't it?

Not really since the A540 has a SCSI harddisc so the size of ADFS buffers
shouldn't make ANY difference.

Rob.

I have an A5000 with R3.0. I was told to set my adfsbuffers to 0K due to a bug
in the OS, but this caused floppy disk read/write to be much too slow. What
should I have my adfsbuffers set to?

Also, writing to a PC format disk is very slow. Might have have something
incorrectly configured which is causing this?

Thanks for any help given,
	Richard
-- 
Richard Broadley,	       (      ...  rebroad@uk.ac.warwick.dcs      .
Dept of Computer Science,      )      ..    csudp@uk.ac.warwick.csv      ..
University of Warwick,         (      .     rbroadle@isis.cs.du.edu     ...
Coventry CV4 7AL, UK           )      .....................................

In article <1992Dec20.011534.5366@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:

>   That is, I
>   get the impression that setting a large value for ADFSBuffers will NOT
>   have ANY effect on a SINGLE file, but using (e.g.) 256 buffers will allow
>   up to 256 files to be buffered simultaneously.
>   A value like 8 or 16 will probably be plenty - this will allow pretty much
>   all the files you ca expect to be open at any time to be buffered.

Actually adfsbuffers does have a dramatic effect on reading
and writing a single file. Using my RISC OS tar for a large hard disc
backup with compression, I normally set adfsbuffers to 255. Then
writing to the disc happens in the background and the compression
of a file can begin before the preceeding file has been completely
written to disc. This also works under taskwindows, so you get
somewhat better preemptive multitasking.

Alas there seems to be some kind of bug in the filing system as
it sometimes causes the machine to hang (and that gets really awful
if the disc maps are just being written). So if I'm doing a complete
backup of my hard disc I use the raw disc writing option in tar
which uses ADFS_DiscOp and avoids adfsbuffers.

-- Frank Lancaster, fl@tools.de

In article <1h2up3INNncc@lily.csv.warwick.ac.uk>, csudp@csv.warwick.ac.uk (Mr R E Broadley) writes:
> I have an A5000 with R3.0. I was told to set my adfsbuffers to 0K due to a bug
> in the OS, but this caused floppy disk read/write to be much too slow. What
> should I have my adfsbuffers set to?
> 
> Also, writing to a PC format disk is very slow. Might have have something
> incorrectly configured which is causing this?

   Yes the slowness is due to ADFSBuffers not being configured. However if
your machine has a hard drive (and I have yet to hear of an A5000 without one)
*DO NOT* configure ADFSBuffers on! There is a bug in the RO3.00 implementation
of ADFSBuffers that causes hard drive access' to deliver random Address
Exceptions, errors and occasionally corrupt freespace maps.

   Because the errors are random you will have a hard time tracking it down
if you aren't aware of this problem.

   What this means is that you will have to live with slow floppy access' till
you upgrade to RO3.1 which has that problem cured. (Mind you it has a nice
new one just for fun. Thankfully it is only a real problem when low 8- buffers
are configured.)

   Philip

In article <FL.92Dec21130356@pierre.tools.de> fl@tools.de (Frank Lancaster) writes:
>
>Actually adfsbuffers does have a dramatic effect on reading
>and writing a single file. Using my RISC OS tar for a large hard disc
>backup with compression, I normally set adfsbuffers to 255. Then
>writing to the disc happens in the background and the compression
>of a file can begin before the preceeding file has been completely
>written to disc. This also works under taskwindows, so you get
>somewhat better preemptive multitasking.

I noticed this! Having just upgraded to RO3.1, I managed to do my
long-delayed HD backup with tar in a taskwindow. The best part was, it got
through all 70 floppies without a hitch! Under RO2, the machine would
always hang at some really annoying moment, like disc 20. It was also
noticably faster than under RO2.

Graham