harald@ccicpg.UUCP ( Harald Milne) (10/16/87)
My big question is, if 1.3 enhancements for the hard disk arrives, what
impact will this have on Ethernet interfaces? Do they share the same I/O
bottlenecks? Will improvements on the OS interfaces regarding I/O affect
Ethernet as well as the hard drives?
--
Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG)
Irvine, CA (RISCy business! Home of the CCI POWER 6/32)
UUCP: uunet!ccicpg!haralddillon@CORY.BERKELEY.EDU (Matt Dillon) (10/17/87)
> My big question is, if 1.3 enhancements for the hard disk arrives, what >impact will this have on Ethernet interfaces? Do they share the same I/O >bottlenecks? Will improvements on the OS interfaces regarding I/O affect >Ethernet as well as the hard drives? Software wise.... none. NFS is usually done via a DOS device of sorts and never touches the hard disk interface. Since this device probably goes directly to the ethernet controller, changes to the OS would not effect its efficiency. -Matt
harald@ccicpg.UUCP ( Harald Milne) (10/18/87)
In article <8710171825.AA13108@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > My big question is, if 1.3 enhancements for the hard disk arrives, what > > impact will this have on Ethernet interfaces? Do they share the same I/O > > bottlenecks? Will improvements on the OS interfaces regarding I/O affect > > Ethernet as well as the hard drives? > > Software wise.... none. NFS is usually done via a DOS device of > sorts and never touches the hard disk interface. Since this device probably > goes directly to the ethernet controller, changes to the OS would not effect > its efficiency. > > -Matt 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? -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/19/87)
: 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....). 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. The throughput of RAM: is about 873K/sec reading, so this can be considered the 'theoretical' limit. 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!!!). An NFS to a host which uses a good layout can be *much* faster! E.G. and NFS to a SUN or VAX host. -Matt
andy@cbmvax.UUCP (Andy Finkel) (10/20/87)
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.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/20/87)
:> :> 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. Ahhhh!!!!!! That 873K/sec for VDK: did sound a little fast to me. I was under the impression that VDK: was a simulated trackdisk.device ... my mistake. This changes my analysis somewhat: Noting the differences in speed between VD0: and VDK: ... approximately 8x, one can assume that the DOS interface to a trackdisk device (VD0 simulates a trackdisk device) is extremely inefficient. This, compounded by an inefficient disk layout, is why DOS is so slow with hard drives. -Matt
harald@ccicpg.UUCP ( Harald Milne) (10/20/87)
In article <8710182253.AA05929@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > 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!!!). Seeks! Yucc is right. Doing DMA doesn't really matter if you have to wait milliseconds for the head to travel back and forth. I got a 20meg supra drive, and was very unhappy in the performance. But I knew this before I got it, I just needed mass storage at the time. (It's hard to put a 1.3meg file on a 880kb floppy!) > An NFS to a host which uses a good layout can be *much* faster! > E.G. and NFS to a SUN or VAX host. I thought about this a little more, and I realized that the Amiga running as a client to a host file server wouldn't have to deal with DOS! There is no Amiga anything on the other side, just UNIX. So it's just a matter of how fast you can pump the data into memory off the Ethernet. (Well also how loaded the server is, how much traffic on the net, etc. Damm NFS, it's so invisible your forget it's there, much less how it works!) With that in mind, I wonder which will be faster, the rumored 1.3 ehancement that require mount or bindrivers command (kiss the supra off, unless they start conforming to spec's) or NFS? I'll dig into NFS bandwidth. Offhand it look's close. That's assuming 150kb. Any developers care to comment since CATS can't. While on the subject of harddisks, I am doing simulations of SCSI drives on UNIX, and found out that SCSI drives will buffer a track, unless you hit it with another seek request in which case it aborts and does a seek. Yucc! The buffering only helps if your next request is on the same track, which in the case of UNIX read ahead works sometimes. Add to the headache that UNIX only feeds sorted seek requests one at a time to the driver, the file system has to be modified. Oh well! I am spoiled to the power of my company's UNIX systems, so mention of Suns or Vaxs tend to make cringe, no offense. I guess that's considered a plug, so disclaimer here. I am getting the Ameristar A2000 Ethernet card, which is why I brought all this up. If anyone is interested, I can post throughput of file transfers, on unloaded file servers. Special thanks to Matt! -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
root@sbcs (Root) (10/21/87)
In article <3151@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) 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? NFS can run faster than an Amiga hard disk, at least using the "old" (ie current) filesystem. Why? Because most NFS servers I know of are running on machines which use the Berkeley FFS - FFS squeezes quite a bit more performance out of a given disk that does the current AmigaDOS format. Expect this to change once C=A releases their new filesystem. Note that Ameristar has never sold NFS as a cheaper, faster hard disk replacement - the strengths of networked disks are sharability of data, better economy of scale in sharing one large drive over several machines, and of course linking the Amiga into pre-existing networks. > -- > Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) > Irvine, CA (RISCy business! Home of the CCI POWER 6/32) > UUCP: uunet!ccicpg!harald Rick Spanbauer SUNY/Stony Brook (& Ameristar)
daveh@cbmvax.UUCP (Dave Haynie) (10/22/87)
in article <8710171825.AA13108@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: >> My big question is, if 1.3 enhancements for the hard disk arrives, what >>impact will this have on Ethernet interfaces? Do they share the same I/O >>bottlenecks? Will improvements on the OS interfaces regarding I/O affect >>Ethernet as well as the hard drives? > Software wise.... none. NFS is usually done via a DOS device of > sorts and never touches the hard disk interface. Since this device probably > goes directly to the ethernet controller, changes to the OS would not effect > its efficiency. > -Matt Well, yes and no. It depends upon what's changing, and what isn't. If your NFS is implemented as a device using the built-in file system, as are the floppies and the current hard disks, its possible that an enhanced/improved/ whatever file system could drive the NFS.device more efficiently, just as it might drive a harddisk.device more efficienly. If, instead, the NFS implementation is a complete handler (I think this the more likely of the two possibilities), then some hard disk speed up won't effect it directly. Or, graphically, some DOS devices look like this: DOSNAME: -> Dos-Handler -> Exec.Device (DF0:, DH0:, VD0:) while others look more like this: DOSNAME: -> Dos-Handler (RAM:) Of course, mainly what you want in an NFS or other shared file system is to get files off someone else's hard disk, so if your host is an Amiga, a Hard Disk speedup will likely help your performance on the net as much as on the host itself. And of course, if anything is done to speed up the general DOS system itself (eg. a faster system interface to each handler), then the performance would increase as well. This kind of performance increase would be automatic when the new OS was installed, while an increase through use of an alternate filesystem handler might have to wait for the next release of your exec device, since most devices currently don't support multiple file systems. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat
peter@sugar.UUCP (Peter da Silva) (10/22/87)
> 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's VDK:? Where can you get it? Why is VD0: so much slower? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (10/23/87)
I'd like to throw together a terminal evaluation package for Stanford, consisting of an Amiga 500 and monochrome monitor. Things that would be nice to have include: NFS over SLIP TeX Preview (I can handle this one) H19 (yes, you heard that right) emulation X windows (.10 or .11) Tektronix emulation These will be for people who don't want to learn anything about the Amiga, of course, so the system has to be as foolproof as possible. I mean, a master disk in the floppy drive which never gets removed. Any help on any of these would be appreciated . . . -tom
carlos@io.UUCP (Carlos Smith) (10/27/87)
In article <3178@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: > With that in mind, I wonder which will be faster, the rumored >1.3 ehancement that require mount or bindrivers command (kiss the supra off, >unless they start conforming to spec's) >UUCP: uunet!ccicpg!harald The Supra hard disks, contrary to rumor and misinformation, DO in fact auto- configure and conform to standards. If the disk is not partitioned, there is no need to use the 'supramount' command, the 'mount' command will work fine. All 'supramount' does is put together partitioning information from devs:supra.0 with the data in mountlist to do the mount. This lets the user use the nice partitioning/formatting program provided to set up partitions without having to set up entries in the mountlist manually. I had the same concern as Mr. Milne regarding the new filesystem. The folks at Supra told me that there is no problem, and they are already beta testing the new FS. They also told me that if one desired to they could take the information from supra.0 and use it to build separate entries in the mountlist for each partition, thus allowing the use of the 'mount' command with multiple partitions. I looked at supra.0, and sure enough, all the required data was there. So I left well enough alone, until the new filesystem shows up anyway. I have no relation to Supra other than as a happy customer. -- Carlos Smith uucp:...!harvard!umb!ileaf!carlos Bix: carlosmith