Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uwmcsd1!lakesys!jason From: jason@lakesys.UUCP (Jason) Newsgroups: comp.sys.atari.st Subject: Re: my ideal cache program Summary: No, but it wouldn't have to always be a Track, persay Message-ID: <796@lakesys.UUCP> Date: 6 Jul 88 03:08:41 GMT References: <157@cstw01.UUCP> <2752@bath63.ux63.bath.ac.uk> Organization: Lake Systems, Milwaukee Wisconsin Lines: 29 In article <2752@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) writes: > > My (rather limited) investigations lead me to believe that your '(optional) > read-ahead' -- i.e. convert sector reads to track reads and cache the whole > track -- unless of course you've already got it -- probably offers the > greatest potential for speedup. However, I haven't yet designed such a thing > clever enough to deal with the fact that not all my disks are laid out with > the same number of sectors/track. > > Cheers, Paul No, you wouldn't be able to figure out exactly what a track was, but it wouldn't seem that it would matter all that much... The things that need the most speedup are the floppies, so you could use the Sectors/Track value from the floppies (Of course, there may be problems there too, due to the different formatters running around), and just use the same value for HD buffering. It would seem that even though you'd get more seeks than would be completely optimal, it'd be an improvement over the original (non-buffered) scheme. Of course, you could have a config (or run-time if it were a DA) that would allow the user to set different sector/track ratios for each unit (drive letter, whatever you want to call it), with reasonable default values. This would allow for a very respectable speedup for those who don't know much about the guts of their machine, and a larger speedup for the techies in the crowd. -- Jason - Not your average iconoclast