Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!cbmvax!andy From: andy@cbmvax.UUCP (Andy Finkel) Newsgroups: comp.sys.amiga Subject: Re: Amiga NFS Message-ID: <2543@cbmvax.UUCP> Date: Mon, 19-Oct-87 17:38:54 EDT Article-I.D.: cbmvax.2543 Posted: Mon Oct 19 17:38:54 1987 Date-Received: Tue, 20-Oct-87 22:36:49 EDT References: <8710182253.AA05929@cory.Berkeley.EDU> Reply-To: andy@cbmvax.UUCP (Andy Finkel) Organization: Commodore Technology, West Chester, PA Lines: 93 In article <8710182253.AA05929@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >: My understanding of the hard disk throughput problem is OS related, not >:driver related. From what I have heard, even DMA hard disks suffer greatly from >:this problem. NFS being a DOS device, would only share in this headache. The >:bottome line is, NFS can't run faster than a hard disk, bandwidth asside. >:Am I wrong? > > We are all familar with the ram disk (RAM:), and the floppy >drive (DF0:). The difference between the two is that the floppy goes >through two levels of devices: DOS, and the trackdisk, and RAM: goes >through only one level (no trackdisk). RAM: accomplishes this by handling >all the DOS packets (openning files, traversing directories, etc....). Actually, the RAM: handler is just that...a separate handler kind of optimized to the way ram memory actually works. That's how it gets it speed. That, and its internal data format. We have several things operating which give us our speed or lack thereof. One is the default file system handler. It does several things badly, because our trackdisk.device operates differently than the device it was designed for. (and, it operates badly for hard disks, as well. Recently I was told that it was designed for 8" floppies. Believe it or not. Anyway) The default file handler has a couple problems. One is the order it does its seeks. Another is the way it follows directory chains. Another is its buffer scheme. (no comments, please :-) ) Another is its allocation/deallocation of bitmap blocks. Another is its links within data blocks...great for recoverability, but awful for speed. Fortunately, there are answers. DOS supports alternate file systems. That's the good news. The bad news is that the file system must be in place when the device is mounted. The current file system does not have a dismount option. What this means is that until a future Rom Kernal release, you can only use a faster file system with hard disks. Fortunately, this seems to be a popular place to use one. > > Is DOS notoriously slow when dealing with the trackdisk.device? >The theoretical maximum throughput through a trackdisk.device can be >characterized by VD0: or VDK: . The statistics are wildly different, going >from 119K/sec for VD0:, to 873K/sec for VDK: reading. What we're seeing here is the maximums for the default file system handler (VD0:) and the handler built into VDK: (yup, its got its own) I haven't actually checked the max of the default handler, though, but 120K/sec is probably in the ballpark. > > The throughput of RAM: is about 873K/sec reading, so this can be >considered the 'theoretical' limit. Probably someone can still outhack Neil and Tim, and produce a still faster one. Who knows ? It's not a theoretical limit, though. More of a practical one. I mean, the use of larger sectors has hardly begun to be explored :-) > > Thus, the slowness one experiences with HARD DRIVES is probably due >to an inefficient layout on the HD. DOS has a bad habit of putting it's >sector lists far away from the data sectors themselves, causing lots of >seeking when reading (two seeks every 32K ... yuccc!!!). Not to mention...the things I mentioned above. > > An NFS to a host which uses a good layout can be *much* faster! >E.G. and NFS to a SUN or VAX host. As can a hard disk. > > -Matt What's that quote from App*e again ... "It is not the policy of ... Computers to comment on any future product that may or may not be under development." Yea, that's the one. And that goes for our fast file system, too. andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.