home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / acorn / tech / 1079 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.4 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!stc!nnsgs50!rap
  2. From: rap@nnsgs50.tcom.stc.co.uk (Richard Porter)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: adfsbuffers
  5. Date: 18 Dec 1992 13:28:31 GMT
  6. Organization: BNR Europe Limited
  7. Lines: 23
  8. Message-ID: <1gsjlvINN6p1@bnsgd245.bnr.co.uk>
  9. References: <1992Dec18.113330@informatik.uni-kl.de>
  10. NNTP-Posting-Host: nnsgs50.lon40.nt.com
  11.  
  12. In article <1992Dec18.113330@informatik.uni-kl.de>
  13. m_sattle@informatik.uni-kl.de (Matthias Sattler) writes:
  14. >What are adfsbuffers really good for?
  15.  
  16. >They should speed up the (hard)disc access but in fact they don't.
  17. >I tried many different tests (hd-speed tests, compiling c programs, ...)
  18. >on the harddisc of my A540 (RO2) with adfsbuffers 0 and adfsbuffers 256k.
  19. >EVERY test with adfsbuffers configured was slightly slower than the test
  20. >without adfsbuffers.
  21. >Hmmmmmm... funny isn't it?
  22.  
  23. Well, it's interesting that you should say that, but it doesn't concur
  24. with my experience on an A5000. With ADFSbuffers set to 16 as in the
  25. supplied configuration I found that Acorn DTP fell over at the slightest
  26. excuse, particularly if you gave it anything difficult to do or didn't
  27. give it all the available gigabytes before you started. The cure for this
  28. was to set ADFSbuffers to 0.
  29.  
  30. Having done this I noticed that the desktop appeared to be much slower
  31. and there was much more hard disk activity while it was redrawing windows,
  32. particularly !Draw windows with a lot of text using disk-held fonts.
  33.  
  34. Richard
  35.