dillon@CORY (Matt Dillon) (10/02/86)
This isn't a flame, but what I hope is some constructive criticism of the amiga's current disk buffering scheme: It's pretty well useless. Where it fails: (1) JOIN happens to be unbuffered. Thus if you JOIN two large files on a disk and the destination is the same disk, the drive seeks every 512 bytes (or abouts) and takes FOREVER to do the operation. (2) Two processes trying to read the disk, or one reading and one writing (etc...) causes excessive seeks. (about one every 512 bytes.. that's BAD) (3) Run'ing one command in the background and while it's loading trying to execute another command. (same as (2)). The point: Sector caching fails when your reading sequential files The solution: One track buffer isn't enough. Why not make it configurable? Even better, you can have both sector caching and N (2+) track buffers (just make sure you aren't sector caching anything in the track buffer). I realize that track buffers cost in memory, but then, that's why you make it configurable. This would solve a great many problems, the least of which being that we would then be able to use Multi-Tasking efficiently with DOS. Ya? It isn't even fancy. -Matt
hadeishi@husc4.harvard.edu (mitsuharu hadeishi) (10/03/86)
In article <something@cory.Berkeley.EDU> Matt Dillon writes: >The solution: One track buffer isn't enough. Why not make it configurable? Matt, don't you have a copy of 1.2? There is an AddBuffers command which does exactly what you want. Well, not exactly, but it SURE helps. You can specify how many track buffers you want for either df0: or df1: (or df2: or df3:) although they are limited to being in CHIP RAM. Still, with about 30 track buffers per drive and with some extended memory it helps a LOT (esp. with linking!) -Mitsu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/03/86)
Yes, of course I know about AddBuffers. I thought I made it clear that what Addbuffers does is NOT what is needed (or am I wrong? Does AddBuffers cache sectors or tracks?) In any case what currently exists is almost useless. It helps a little on directories, and very small executables, but not much else. I want to be able to read two semi-long files off disk at the same time without a track to track every 512 bytes, as is happenning currently. I think that multiple track buffering WITHOUT sector caching (or reserving sector caching to accesses which are way off key) would work an order of magnitude better than the current scheme. -Matt
erickson@cbmvax.cbm.UUCP (Lee Erickson) (10/03/86)
In article <305@husc6.HARVARD.EDU> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >In article <something@cory.Berkeley.EDU> Matt Dillon writes: >>The solution: One track buffer isn't enough. Why not make it configurable? > > Matt, don't you have a copy of 1.2? There is an AddBuffers >command which does exactly what you want. Well, not exactly, but >it SURE helps. You can specify how many track buffers you want >for either df0: or df1: (or df2: or df3:) although they are limited to >being in CHIP RAM. Still, with about 30 track buffers per drive >and with some extended memory it helps a LOT (esp. with linking!) > > -Mitsu Sorry, but the AddBuffers command adds AmigaDOS SECTOR buffers, not trackdisk TRACK buffers! The AmigaDOS file system handler keeps directory information in these buffers, and it certainly does help, but the problem Matt is complaining about still remains. - Lee -- Lee Erickson - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!erickson but no way officially representing arpa: cbmvax!erickson@seismo.css.GOV Commodore, Engineering Department
cc1@locus.ucla.edu (Michael Gersten) (10/04/86)
This is something that I reported to Amiga a while ago. The problem is that
the system does no read ahead--the hardware requires that an entire track
be read in, but it then only buffers the one sector that you asked for, and
discards the other 10.
Note that the actaul track is not discarded until another track is read, but
that usually is very fast. I'd really like to be able to set the buffers to 40,
and have all 11 put into the buffers, and re-use the buffers on a LRU
scheme, sharing all 40 among ALL drives, not 40 for each drive.
Well, commodore? Can we expect this is 1.3?
Michael Gersten
Views expressed here may not be those of the Computer Club, UCLA, or
anyone in their left OR right mind. And that's the name o' that tune.