Path: utzoo!utgpu!attcan!uunet!convex!killer!texbell!merch!cpe!hal6000!trsvax!uhclem From: uhclem@trsvax.UUCP Newsgroups: comp.sys.tandy Subject: Re: Tandy 6000 Hard drives Message-ID: <193300080@trsvax> Date: 9 Nov 88 16:13:00 GMT References: <106@xenlink.UUCP> Lines: 59 Nf-ID: #R:xenlink.UUCP:106:trsvax:193300080:000:3418 Nf-From: trsvax.UUCP!uhclem Nov 9 10:13:00 1988 <> R2>While we are discussing hard drives on the Tandy, I was wondering if anybody R2>else has played around with the interleave. I did a test last year with 10 R2>different values and had no difference in speed. As near as I can tell the R2>Z80 combined with the controller always reads in an entire track using the R2>controller track read instead of retrieving individual sectors. Anybody R2>know better or can anyone support this theory? Sorry, the Z80 only reads the requested blocks and the controller can only hold a single block at a time. I suspect your benchmarking method is faulty. Physical disk format interleaves will only improve raw and swap access speed. Non-raw (normal) disk requests are copied through cache buffers in the 68k memory and subsequently the Z80 is handed single block read requests, even if the user read call was for numerous blocks. This is because the cache blocks probably won't be contiguous and when the Z80 gets a multi-block request, it stores/loads the data to/from memory sequentially. (This is standard UNIX/XENIX disk strategy.) To compensate, mkfs allows the fs free-list to be "interleaved" as well. More on that in a second. If you perform a test that causes the swapping of large programs, or more reasonably, read large amounts of data with single calls to the raw device (no naughty writing unless you don't care about the target drive), you will be able to set your physical interleave to optimum for swapping. For normal day-to-day single block disk access (including program loads), the mkfs interleave factors should be adjusted to a number that matches the response time and overhead of the CPU. All mkfs does is sort the free-list it creates so that the blocks of files are spaced far enough apart to compensate for the added overhead of going through the cache buffers. (As the fs is used, the "interleaving" of the fs is gradually lost.) Depending on the version of XENIX 3 you are running, 7 17, 8 17 and 9 17 may have been used. Look at the installation script to confirm which. Note that by default the hard disk interleave is 3:1, so there will be three mkfs interleave numbers that will be close to perfect for you and these are NOT adjacent. I believe they were 9 17, then 14 17, then 3 17 in one version. If the disk interleave is 4:1, there will be four of these points, and so on. Get yourself a big piece of paper and draw out the interleave and you can work it out, or you can do what we did: try all 17 combinations for each physical interleave. You can either use dd from the raw device to null in large quantities or write a program to do a similar activity. Do not use the dread program from the BYTE benchmarks, it randomly accesses blocks to emulate fs activity. Once you settle on the physical format interleave, a secondary drive can be used to determine the mkfs values without having to install over and over again. "Thank you, Uh Clem." Frank Durda IV @ ...decvax!microsoft!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem "You've got a nice network here. We wouldn't want something to happen to it."